OpenVPN Service

Advanced feature discussion, beta programs and unsupported "Labs" features.
64 posts Page 4 of 7
by pmbell » Tue Mar 01, 2016 4:43 pm
Please hold onto the Lite until you are able to test it out on the Fusion product.

It would be great to see some real world throughput comparisons in the FTTN context.

I'm glad I let you hold onto it so long!

forest wrote:
matausch wrote:
What kind of speeds do you see with this router?
It's a cheap device and if speeds would hold up it would be the perfect "all home" Vpn solution so many seek.
I found that is has only a dual core 880 MHz cou so I guess the speeds are low on vpn. What is your speed with vpn on?

I don't have an EdgeRouter X yet (I'm borrowing an EdgeRouter Lite), and my Fusion ADSL service is so bloody slow that it can't test any router's throughput. I can take some measurements once I have the device and FTTN. I expect it will be a few weeks.

Based on this thread and other discussions I've found scattered about the net, I have the impression that the EdgeRouter X should handle Sonic's 20mbit/sec FTTN just fine, even with OpenVPN, NAT, and firewall. Not sure about FTTN x2 under those conditions, but I wouldn't be surprised if wire speed was achievable there, too.
by netllama » Tue Mar 01, 2016 5:31 pm
kkl0 wrote:
Hello.

I need some help from Sonic and user community with an issue I'm having with the OpenVPN service at ovpn.sonic.net using the Windows OpenVPN Connect client. I'm able to connect and establish session but it constantly drops/disconnects and then reconnects again. Most of the time the drop happens within 5-10 minutes. The longest session that I've been able to establish was about 1 hr 20 mins. Not sure if everyone else is having this similar issue.

Your help is most appreciated. Thanks.


How did you determine that the VPN connection is dropping?

Are you sure that this isn't a problem with your internet connection? Do you have a secondary device that you can use to test the VPN (a cell phone, laptop, etc)?
by kkl0 » Tue Mar 01, 2016 11:01 pm
netllama wrote:
kkl0 wrote:
Hello.

I need some help from Sonic and user community with an issue I'm having with the OpenVPN service at ovpn.sonic.net using the Windows OpenVPN Connect client. I'm able to connect and establish session but it constantly drops/disconnects and then reconnects again. Most of the time the drop happens within 5-10 minutes. The longest session that I've been able to establish was about 1 hr 20 mins. Not sure if everyone else is having this similar issue.

Your help is most appreciated. Thanks.


How did you determine that the VPN connection is dropping?

Are you sure that this isn't a problem with your internet connection? Do you have a secondary device that you can use to test the VPN (a cell phone, laptop, etc)?


I've tested the VPN on my iPhone and it worked fine. The issue is happening on my laptop. There is no issue with my internet connection.

I did some further testing on my laptop and discovered that drops are occurring when I connect to the internet using my Sonic service/connection (either via wifi or hard wired Ethernet). However, when I connect my laptop to the internet using my 4G LTE service MiFi device, the VPN works fine with no drops. Weird. Something I'm not figuring out. Please help. Thanks.
by forest » Thu Mar 10, 2016 7:15 pm
I just noticed that Sonic's server certificate doesn't include the X509v3 Key Usage or Extended Key Usage properties, meaning that openvpn's "remote-cert-tls server" option cannot be used to prevent man-in-the-middle attacks. Can you folks please issue a new server cert with those properties set appropriately? I don't expect there would be any customer impact, assuming the CA certificate remains unchanged.

While the existing server certificate does have the similar nsCertType property, and the generated client .ovpn files contain the option that checks that property, I learned today that nsCertType is apparently deprecated in favor of the newer properties described above. To make matters worse, it turns out that some OpenVPN implementations (e.g. the one in GNOME NetworkManager) strip out the deprecated option when importing a config file, effectively removing the MITM protection from the .ovpn files currently generated by Sonic's server.

Of course, it would also make sense to include one or both of these in the generated .ovpn files:

Code: Select all

remote-cert-tls server
verify-x509-name 'CN=OpenVPN Server'
by kgc » Fri Mar 11, 2016 11:25 am
I've been assured that this isn't a problem for the OpenVPN AS commercial server and that the documentation that implies it is required should be viewed as being specific to the open source version.
Kelsey Cummings
System Architect, Sonic.net, Inc.
by forest » Fri Mar 11, 2016 1:19 pm
kgc wrote:
I've been assured that this isn't a problem for the OpenVPN AS commercial server and that the documentation that implies it is required should be viewed as being specific to the open source version.


I don't understand that claim. Regardless of whether Sonic has an OpenVPN AS commercial server or the open source server, how can it prevent a client from connecting to some other server (commercial or otherwise) that has a valid certificate? It can't.

I have read through the ovpn files you're currently generating for customers. As of today, they contain only two tests to determine whether a client is talking to a valid server:

#1: The <ca> clause says to check that the certificate presented by the server is signed with Sonic's CA key. That's a start, but since every customer's client certificate is also signed with that same CA key, anyone in the world who can get a Sonic account (or borrow or compromise someone else's) can set up a server that passes that test. That's practically no protection at all.

#2: The "ns-cert-type server" directive says to check that the certificate presented by the server contains the corresponding nsCertType property. Since you're only putting that property in the server certificate (not in customer certificates), this test works in concert with the <ca> clause to effectively validate the server, but only on openvpn clients that honor the ns-cert-type directive. I learned yesterday that this directive is deprecated (meaning it won't be supported in newer openvpn clients) and is already ignored by certain systems in the field (I happen to have one).

I have downloaded and examined your server certificate. As far as I can tell, there simply isn't anything else in there that your client configs are checking.

This means that, with your current configuration, some systems are already vulnerable to a man-in-the-middle attack, and more will become vulnerable when support for the deprecated ns-cert-type directive is dropped.

The following directives could fix this problem. I suggest implementing at least the first two, along with the server certificate properties to support them. The third is deprecated, but might still be worthwhile for the sake of older clients. (For anyone else reading along, the "OpenVPN Server" text could really be anything; its only importance is that it match Sonic's server certificate and not match any of the customer certificates they issue.)

Code: Select all

remote-cert-tls server
verify-x509-name 'CN=OpenVPN Server'
tls-remote /CN=OpenVPN_Server


The assurance you mentioned receiving just doesn't make any sense to me. If your vendor has more information that would illuminate the problem, or call attention to something I might have missed, I'd love to see it. At the moment, though, it looks like that person was just confused.
by kgc » Fri Mar 11, 2016 1:29 pm
forest wrote:
The assurance you mentioned receiving just doesn't make any sense to me. If your vendor has more information that would illuminate the problem, or call attention to something I might have missed, I'd love to see it. At the moment, though, it looks like that person was just confused.


Have you tried to run a server with the client key?
Kelsey Cummings
System Architect, Sonic.net, Inc.
by forest » Fri Mar 11, 2016 1:47 pm
kgc wrote:
Have you tried to run a server with the client key?


No. So far, I've been assuming that the people who developed openvpn knew what they were talking about when they issued the warning. Besides, my understanding of TLS and certificate validation give me every reason to believe it.

As I said, I suppose it's always possible that I might have missed something important, but I've spent so much time on this lately that it seems unlikely. Staging an actual attack seems like an unnecessary waste of time at this point.

Are you thinking that an attacker's server might refuse to serve the certificates you are issuing to clients? Any such check could be defeated by simply changing the source code.
by timyu94 » Sat Mar 12, 2016 12:53 am
(Might be a stupid question)

Is there any chance that the OpenVPN service will utilize IPv6 anytime soon?

I have the uverse FTTN service and decided to enable IPv6 for the hell of it to test out if ATT's IPv6 implementation still lags / times out sites. I currently run the VPN on my Asus AC87 router and did a IPv6 test which showed an IPv6 connection via ATT while the IPv4 connection via went through Sonic.

While it isn't much of a problem as I've kept IPv6 off for years, it's a tad concerning that IPv6 traffic goes through att as their traffic shaping and subsequent buffering annoys the hell out of me and defeats the purpose of running the VPN.
by ashes » Sat Mar 12, 2016 3:43 pm
kgc wrote:
There's no 24 timeout, and shouldn't be on beta.vpn.sonic.net anymore either.


Thank you so much for removing the 24 hour timeout. Trying to cope with it was crux of my issues in getting my whole-home-VPN router configuration to a happy place. Aside from privacy issues, AT&T's absurd traffic shaping drives me to whole-home-VPN for basic quality-of-service issues, e.g. reliable youtube.
64 posts Page 4 of 7

Who is online

In total there is 1 user online :: 0 registered, 0 hidden and 1 guest (based on users active over the past 5 minutes)
Most users ever online was 422 on Sat May 26, 2012 5:28 am

Users browsing this forum: No registered users and 1 guest