OPEN VPNdown after maintenance?

[faisal]

The beta vpn server does play well with EdgeOS. Now to see how long it takes Ubiquiti to get around to shipping an EdgeOS 2.0 beta.

Are any of you running a site-to-site VPN but did not experience issues do to this update? If so, what hardware are you using?

[virtualmike]

I'm running:

Windows 10
Open VPN GUI v11.10.0.0
Open VPN Daemon 2.4.5.0

I'm seeing a couple of warnings in the log file:

Code: Select all

WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
[...]
WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

I'm assuming the latter is because I've checked the "Remember Password" on the connection dialog. Since no one else has access to the computer, I'm not concerned about that.

However, the first item is a concern. I found this in the Sonic.ovpn file on my computer, generated last August:

Code: Select all

ns-cert-type server

I grabbed the latest client.ovpn from ovpn.sonic.net, and it has the same ns-cert-type setting. Should I be concerned about this?

The latest client.ovpn file also has this setting:

Code: Select all

setenv opt tls-version-min 1.0 or-highest

As far as I can tell, OpenVPN works with the August file. Other than the cert error, any need to switch? ...thanks!

[Elmatador2]

Got the openvpn running correctly. I've got an Asus router that I had updated to the latest firmware before I started this thread and it didn't work.

I then searched and found out that Asus Merlin firmware(https://asuswrt.lostrealm.ca/) gives more control over the router(Support for new OpenVPN 2.4 features like NCP and LZ4). Backed up my router, re-flashed with the latest Merlin and ipchicken.com show's I'm on the Sonic network. Geo locate(https://www.where-am-i.co/) also show's I'm coming out of a tunnel up north.

[guest]

Thanks for posting the supported ciphers. For what its worth I added AES-256-GCM to NCP and re-enabled on the pfSense Sonic vpn client page and all is good.

Code: Select all

openvpn 	73433 	Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
openvpn 	73433 	Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
openvpn 	73433 	Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
openvpn 	73433 	VERIFY OK: depth=0, CN=OpenVPN Server
openvpn 	73433 	VERIFY X509NAME OK: CN=OpenVPN Server
openvpn 	73433 	VERIFY OK: depth=1, CN=OpenVPN CA 
openvpn 	66692 	OpenVPN 2.4.4 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Mar 16 2018

[forest]

Code: Select all

WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.

I grabbed the latest client.ovpn from ovpn.sonic.net, and it has the same ns-cert-type setting. Should I be concerned about this?

IIRC, Sonic's openvpn config directs the client to trust the server if the server's certificate was signed by Sonic's certificate authority. This is a good thing, because it helps prevent a random person from mounting a man-in-the-middle attack, impersonating Sonic's server and intercepting your communications. It's not quite enough, though: Every client config issued by Sonic contains its own certificate that is also signed by that same CA, and is therefore trusted by every other client config. This means that, without an additional check of some kind, literally anybody who can sign up for Sonic service or get their hands on a Sonic customer's password or openvpn config, could impersonate the server.

To prevent this, we need our VPN clients to distinguish between the server's cert and a customer's cert, and reject the latter. The "ns-cert-type server" directive is doing that job. Removing it without first putting something else in place to do that job would be unwise.

The "remote-cert-tls server" directive could take over that job, but it would require Sonic to generate a new server certificate containing the corresponding "key usage" flag. (I believe this could be done without breaking existing clients. It had not yet been done when I checked last year.)

Of course, since the directive currently in use is deprecated, there is a risk that a future openvpn version might drop support for it before Sonic adds the new flag to their cert, leaving us either with broken VPN configs or (if we were to remove the deprecated directive) exposed to MITM attacks. If that should happen, I would suggest replacing the directive with some other one that will reject a client cert if it were ever used to impersonate the server. For example:

Code: Select all

verify-x509-name 'CN=OpenVPN Server'

That might seem a bit hackish, but it would work as long as Sonic never allows a customer to choose a username of "OpenVPN Server".

[virtualmike]

Thanks, Forest!

[guarino]

Hey folks, I just wanted to mention here for those of you that may not be subscribed to our MotD that ovpn.sonic.net will be going down for a brief maintenance window tonight, long enough for me to allocate more memory for the host. During the brief downtime beta.vpn.sonic.net will remain up, so for those of you who would like to swap over in advance please feel free.

https://sonicstatus.com/2018/04/06/open ... tenance-2/

You may want to join the MotD maililng list as well, which you can do here:
https://members.sonic.net/account/motd/
or here:
https://lists.sonic.net/mailman/listinfo/motd

[forest]

Thanks, guarino. It's nice to to have details like this when we depend on the VPN service for connectivity.

[forest]

This failure is happening again, this time on beta.vpn.sonic.net, since midnight. Did you guys forget to keep TLS 1.0 enabled on the beta server?

[guarino]

Hey Forest,

I just replied to your other post about this but yes, TLS 1.0 is still enabled and no changes were made to the openvpn installation
on beta. I see several attempts on the production host but only one on the beta which appeared to succeed. Are you able to try the beta out again?

Thanks,
Justin

[edit: typo]