OpenVPN Open Beta

[fng]

I think the cert issue was brought up before (8/17) and they were going to wait since a cert change would require everyone to download and import the .ovpn file. My guess is they will probably wait until the beta is over or implement it with other changes.

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.

[forest]

I think the cert issue was brought up before (8/17) and they were going to wait since a cert change would require everyone to download and import the .ovpn file.

Not quite. The post you're referring to is about updating the server's certificate. My note is about the client configuration.

[liamk]

Still trying to get a response from Sonic on whether they will change the 24hr session expiration variable in their OpenVPN server configuration. This is starting to get recursive... If there is a reason they don't want to do it, okay. But it would be appreciated by some of us.
My latest attempt, last week:

Hi, Robert,

If you read my message carefully you will see that I included links to
posts in your forums in which the request was already made; however no
one from Sonic has responded there.
I spoke with a Sonic support person today to find out what the status of
the request was. They were unable to help, and suggested I email the
request to [email protected], the message to which you responded with
the suggestion to post it on the forum.

Liam

On 11/04/2015 08:07 PM, Sonic.net Tech Support wrote:
> Hi Liam,
>
> You have reached our Customer Support Team. I recommend placing your request on our forums. Other users can show support and receive feedback from our System Opertions and Network Operations team. Thanks for your understanding.
>
> Robert S. [email protected]
> Sonic.net Support 707.547.3400
> Santa Rosa, CA 95407 http://www.sonic.net/support/
>

[abhi.kris]

Is this program still ongoing or has it been superseded? I just came across this thread and decide to try it out on OS X El Capitan and it seems the Connect client is having a JSON problem?

Here's the error I get when I try to connect:

Code: Select all

Unexpected error: JSONDialog: Error running jsondialog, status=(5, [], ['task_for_pid(): 0x5']), stdout=[], stderr=['task_for_pid(): 0x5']

Any thoughts?

[forest]

Still trying to get a response from Sonic on whether they will change the 24hr session expiration variable in their OpenVPN server configuration. This is starting to get recursive... If there is a reason they don't want to do it, okay. But it would be appreciated by some of us.

I'm eager for this, too. I've been stuck in a 2mbit/sec slow lane ever since my Fusion line quality dropped a couple months ago. It's painful. I need a fix. Sonic FTTN + VPN could be that fix if only they would get rid of this confounded session expiration.

My optimistic side is guessing that it has been stalled merely because Kelsey got extra busy, and that we'll see progress soon. Crossing fingers.

[pmbell]

you could get another VPN provider and go month-to-month while the kinks are worked out for 4-8 bucks/mo.

has anyone tried pm'ing him to ask him to look at the thread? he was very responsive to pm earlier on.

[pcvcolin]

Apart from the horror of the MITM just waiting to happen as mentioned above, I have to say that I think that a much better solution than providing a .ovpn file (client.ovpn) would be instead to provide a .conf file (which I've noticed actually can be imported without problems in Ubuntu 14.04 LTS, Network Connections --> add --> Import a Saved VPN Configuration... (use .conf, and save)

An example of how I've seen this done in an alternative VPN service (free example with config [.conf] file, opnvpn, Ubuntu) is here:
https://cryptostorm.org/viewtopic.php?f=58&t=8725

[kgc]

Any system which does not automatically reconnect, regardless of what the timeout is currently set to, is broken if it is intended to be used as a whole home/fixed vpn solution. Any network event, including regular maintenance, would leave your connection down requiring manual intervention - that doesn't make sense.

The main reason that there is a timeout at all is to force the clients to reauthenticate on a regular interval. If we delete or lock your account it will stop working automatically without us having to specifically write code to seek out and disconnect active sessions. Ideally openvpn would be able to reauthenticate on a specified interval to keep the existing connection but, as far as I know, this isn't possible.

The certificate type and some other options will be tweaked when we deploy the production service.

[forest]

Any system which does not automatically reconnect, regardless of what the timeout is currently set to, is broken if it is intended to be used as a whole home/fixed vpn solution. Any network event, including regular maintenance, would leave your connection down requiring manual intervention - that doesn't make sense.

The main reason that there is a timeout at all is to force the clients to reauthenticate on a regular interval. If we delete or lock your account it will stop working automatically without us having to specifically write code to seek out and disconnect active sessions. Ideally openvpn would be able to reauthenticate on a specified interval to keep the existing connection but, as far as I know, this isn't possible.

The openvpn client does seem to have an automatic reconnect/reauthenticate capability; I can see it trying to do so when I add the right options in the .ovpn file. (I think auth-retry was the option I used to enable this.) However, something about your server configuration seems to cause the reconnecting client to fail authentication no matter how many times it retries. I experimented with a bunch of helpful-looking settings, but the only thing that worked was letting the client process die entirely and then starting a new one.

Regarding the timeout duration: I understand that networks go down once in a while, but forcibly breaking all connections every 24 hours creates a much worse experience than the occasional connection loss due to maintenance. Streaming dies. Programs running over SSH die. Gaming sessions die. Every single day. The several seconds of waiting for a new connection to be established don't make it any better. I've been running with the VPN beta for the past month or so, and it's really frustrating. Not anywhere close to the level of stability I've had from Sonic for years. If the disconnects can't be avoided, I hope you'll consider spacing them out to at least several days.

Or maybe I shouldn't be spending so much time trying to get openvpn to solve the whole-house problem. What's going on with the EdgeRouter-compatible IPSEC VPN I keep reading about? That might be the best solution, since I'm using an EdgeRouter.

[pmbell]

The main reason that there is a timeout at all is to force the clients to reauthenticate on a regular interval. If we delete or lock your account it will stop working automatically without us having to specifically write code to seek out and disconnect active sessions. Ideally openvpn would be able to reauthenticate on a specified interval to keep the existing connection but, as far as I know, this isn't possible.

The certificate type and some other options will be tweaked when we deploy the production service.

Question: which directive are you using to force the connection to reestablish?

On the client side, there is a directive to force renegotiation every X seconds, reneg-sec. From what I've read, the server also has a directive to force that. I find that by telling my client to renegotiate a bit more often than the server expects, the client is able to stay live for very long periods (days to weeks) The main thing is to not have both sides attempting a renegotiation at the same time.

In the beta deployment, could you use that setting rather than the current one (assuming that isn't how you're updating connections already) and update the client certificate for a test bunny^B^B^B^B^B user to see if, when the server forces a renegotiation, the connection dies if the server cert has been changed/deleted for that user? I think it ought, and as long as customers know what the Sonic directive is and to not have theirs set to exactly the same duration, the renegotiation for everyone else ought to work well (or at least it does for me with a different opvenVPN server.)

And once you change (or delete) the certificate assigned to user J. Q. Deadbeat, the next spin of the renegotiation ought to fail as the certs are re-read, no?