Sonic.net

Guest wrote:Potentially dumb question, but is it possible to configure this at the router level yet? I tried once and had no luck.

(using an Asus RT-NT66R behind a Pace 5031)...router natively supports OpenVPN.

I've got at least a dozen or more wireless clients and there's no way I'm going to set up VPN on all of them...

I was able to in pfsense.

the key for me was to get the steps involving the certificates in exactly the right order. wrong order but right certs and it was no-go. if you started and stopped the process, delete any existing certs and CA's before you try again.

Guest wrote:Potentially dumb question, but is it possible to configure this at the router level yet? I tried once and had no luck.

(using an Asus RT-NT66R behind a Pace 5031)...router natively supports OpenVPN.

It works for me using the stock AsusWRT firmware, but it's not the most stable/reliable connection.

Just upload the client config file, and enter your credentials.

I understand the Merlin firmware offers some additional configuration options, but I haven't tried it.

I got tired of toggling the OpenVPN connection off/on to keep it functioning, so I've switched to using the IPSec client build into my OS. It's more stable, but still not completely reliable.

I don't know how robust Sonic plans to make either of these services, and haven't seen any answers.

At this point, neither is what I'd call something one could just set and forget, or up to Sonic standards.

Problem:

I've been test driving this VPN in hopes that using it in a whole-house configuration could bring Sonic's FTTN service up to Sonic's privacy standards. (We don't want AT&T or other agencies looking at our bits, after all.) Sadly, it currently has a deal-breaker flaw: The server forcibly ends VPN sessions every 24 hours.

This means that the VPN fails at least once every day, bringing all internet traffic to a grinding halt*. For most customers, this leaves the whole house without connectivity until their tech person comes home to deal with it. A few households might have someone with the skill and inclination to program an automatic reconnect script, or always have someone present to continually restart the VPN by hand, but connectivity is still lost for at least a few seconds, and the external IP address is often different once the network is brought back up. Music streaming, video/audio chats, multiplayer gaming, remote logins, VoIP telephone calls, and many other applications break because of this behavior. This makes it practically useless as a whole-house solution.

For the past six weeks or so, I've tried to work around this problem using every documented openvpn option that looked relevant, including various combinations of ping, auth-retry, persist-tun, persist-key, remap-usr1, and others. None of them helped. The server would still tear down the VPN in 24 hours or less.

Solution:

I learned yesterday that the 24 hour session expiration is not required, but merely part of a default profile on OpenVPN Access Server. This means Sonic can get rid of it, and fix the problem. The key is apparently the "autologin" profile and/or a very large vpn.server.session_expire value. (I'm not sure whether autologin alone is sufficient or both settings are required.) Details can be found here.

By default, Access Server implements a 24 hour timeout for the server-locked and user-locked profiles. These are the default profile types used. This means that when a user logs in with her or her credentials, the connection can stay online for a maximum of 24 hours. The autologin profile is an exception since this does not require credentials and can stay online indefinitely. The following configuration parameter allows you to alter this timeout setting to your specifications. You can even 'disable' it by setting a ridiculously high timeout value. You will need to run these commands on the console or through an SSH session on the Access Server:

/usr/local/openvpn_as/scripts/sacli --key vpn.server.session_expire --value 86400 ConfigPut
/usr/local/openvpn_as/scripts/sacli start

This will set the timeout to 86400 seconds (24 hours). Adjust this to your liking. If you set it to something like 1000000000 you can effectively disable it so the session doesn't time out.

Dear Sonic folks, will you please fix this?

If the VPN starts working reliably soon, I'll be able to solve my abysmal speed problem without leaving Sonic, by switching to FTTN.

Special thanks to pmbell for lending me his EdgeRouter for testing!

*(Technically, some people might choose to set up their VPN client to fail open instead of fail closed, but this would be even worse, since it would suddenly and silently expose all internet traffic to snooping.)

In addition to the problem described in my previous post, I found some problems in the .ovpn files that get generated for each user:

Potential Server Impersonation:

The openvpn client will happily connect to any server whose TLS certificate is signed by the CA in the user's .ovpn file. This apparently means that the client certificate in any other Sonic user's .ovpn file can be used to impersonate the server. In other words, it's a MITM attack just waiting to happen. The openvpn man page warns of this, and suggests using the "ns-cert-type server" option to guard against it. That option should probably be included when generating .ovpn files for users.

Misleading Comment Clutter:

This is not a direct security risk like the problem above, but it does add needless complexity and misinformation: The vast majority of the generated .ovpn file is comment clutter. It starts with nearly a hundred lines of X.509 certificate chain data, and ends with another hundred and thirty (or so) similar lines, all of which are commented out and therefore not used at all by openvpn. To make matters worse, those certificates do not match the ones presented by the VPN client or server. They look more like web server certificates, but their CA chains don't even match those on the VPN host's web server. I don't know why they are being inserted into the .ovpn file as comments, but they make it harder for users to understand and validate their own site security, so they probably ought to be removed.

Can Sonic comment on the range of IP addresses I should see for OpenVPN connections? I'm experimenting with the beta, and need whitelist the OpenVPN addresses in my hosts.allow file.

Will these addresses move around much (i.e. how big's the block, will is stay there?).

Thanks,

Mark

I don't think I kept the sonic connection running for long enough to be motivated to try fixing the 24 hour issue. my connection usually reestablishes itself after it gets dropped, running in pfsense.

I agree that the ovpn file has a lot of unneeded cruft in it, which is confusing even for those of us who have set these up before.

how do you feel about the performance of the edgerouter in terms of throughput?

pmbell wrote:how do you feel about the performance of the edgerouter in terms of throughput?

Sadly, my Fusion line is too slow to test the EdgeRouter's performance. I'm creeping along at a little over 2 mbit/sec right now, which is why I'm so interested in the VPN becoming stable. Once it becomes reliable, I can order FTTN and report back on router throughput.

I was informed by Sonic support that there was no timeout, however in this thread I have seen references to a 24hr timeout, and I have been getting the following:

Oct 30 03:36:48 DD-WRT daemon.notice openvpn[6977]: AUTH: Received control message: AUTH_FAILED,SESSION: Your session has expired, please reauthenticate

The timeout situation doesn't seem to be handled by the keepalive setting

I am running OpenVPN on DD-WRT (see http://www.freespeechnow.org/ for details).

I can restart OpenVPN on the router, but it gets a bit tedious to do this every day.

Anyone have an idea on either how to restart the OpenVPN process on DD-WRT automatically, or get Sonic to not expire the session after 24 hours?

liamk wrote:Anyone have an idea on either how to restart the OpenVPN process on DD-WRT automatically, or get Sonic to not expire the session after 24 hours?

Please read my post from earlier today:
viewtopic.php?f=10&t=2973&p=22091#p22083

With some work, you might be able to make your router reconnect, but you'll still get broken connections when it happens. Fixing the problem requires that Sonic adjust the Open VPN Access Server settings.

There is a 24 hour server default timeout setting in OpenVPN (vpn.server.session_expire). This can be changed by Sonic if they want. Here is the link to the setting.

https://docs.openvpn.net/docs/access-se ... management

You could use a script or cron to reset your connection. I was lazy and installed "Service Watchdog" in PFSense which automatically restarts the connection if it goes down. I have mine reset late since no one is using the internet then and also it gives me a new ip every 24hrs which is nice.

liamk wrote:
Anyone have an idea on either how to restart the OpenVPN process on DD-WRT automatically, or get Sonic to not expire the session after 24 hours?