OPEN VPNdown after maintenance?

[faisal]

This page suggests Ubiquiti needs to get with the program on OpenVPN versions, but in the meantime we might be able to tweak ciphers on the local tunnel endpoint.

[forest]

Just let me know how I can help. I am eager to have my service restored.

[guest]

Ran into same issue here running pfSense v2.4.3... Sonic VPN client could not connect after Sonic's upgrade - other VPN provider client not affected. Disabled NCP and manually set client encryption to AES-128-CBC on Sonic client page... Restarted service and client connected normally again.

[forest]

Thanks for the tip, guest.

Sonic staff: Those of us whose connectivity you broke could use some help here. Are you going to fix it? Are you expecting your customers to fix it for you? If so, what do you recommend? (Telling us what ciphers are now supported and which ones were removed would be a good starting place, if you expect us to deal with this by ourselves.)

Here's some relevant advice from the OpenVPN wiki regarding compatibility when you upgrade the server:

Migrating away from deprecated ciphers

With the OpenVPN v2.4 release a new feature was introduced, Negotiable Crypto Parameters (NCP). This allows users to seamlessly migrate away from deprecated ciphers without much extra work. If both client and server runs OpenVPN v2.4 without NCP being disabled (--ncp-disable), the tunnel will automatically be upgraded to AES-256-GCM. If the environment also uses clients older than OpenVPN v2.4, the server can deploy:

Code: Select all

--ncp-ciphers AES-256-GCM:AES-256-CBC:BF-CBC

This will allow older clients to add or change --cipher to use AES-256-CBC instead of the default BF-CBC or any other cipher enlisted. This can be done on client configuration files on a one-by-one approach. Unmodified clients will be able to connect as before. Once all clients have been updated to OpenVPN v2.4 or later (preferred) or have their configuration altered, the --ncp-ciphers list can be modified to remove BF-CBC.

[forest]

For the record, I tried manually specifying AES-256-CBC and AES-128-CBC ciphers, but it didn't help. OpenVPN 2.3 doesn't have any ncp options, so I can't disable NCP on my end.

[forest]

Here's someone else with the same symptoms (client receives initial TLS packet from server, but key negotiation fails after 60 seconds). The fix was server-side.

https://superuser.com/questions/1286134 ... n-raspbian

[guest]

For the record, I tried manually specifying AES-256-CBC and AES-128-CBC ciphers, but it didn't help. OpenVPN 2.3 doesn't have any ncp options, so I can't disable NCP on my end.

In my case NCP had both AES-256-CBC and AES-128-CBC selected as options when enabled and worked fine prior to Sonic's recent upgrade... Perhaps they disabled NCP on the server. Regardless, I don't believe OpenVPN v2.3 supports NCP - only v2.4+.

I agree with you though, it would be nice to know which ciphers Sonic currently supports!

[faisal]

See here for a list of changes that came in with the upgrade (we were coming from 2.1.9):
https://openvpn.net/index.php/access-se ... -v200.html

Could you list the ciphers the server supports, in your order of preference that users attempt them?

[guarino]

Thanks for the tip, guest.

Sonic staff: Those of us whose connectivity you broke could use some help here. Are you going to fix it? Are you expecting your customers to fix it for you? If so, what do you recommend? (Telling us what ciphers are now supported and which ones were removed would be a good starting place, if you expect us to deal with this by ourselves.)

Here is the list of currently available ciphers:

Code: Select all

TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA
TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
TLS-DHE-RSA-WITH-AES-256-CBC-SHA
TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA
TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA
TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
TLS-DHE-RSA-WITH-AES-128-CBC-SHA
TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA

The failing clients all appear to be using TLS 1.0. OpenVPN 2.3.2 and earlier only support TLS 1.0. Since the upgrade, the server started requiring a minimum TLS version of 1.1 since 1.0 is considered insecure and being phased out everywhere possible. These clients are continuing to attempt to connect with TLS 1.0 which the server no longer recognizes and is throwing the protocol error.

Due to the insecurity and vulnerabilities in TLS 1.0 and the fact that it's being phased out rapidly, it's not in line with current standards to continue to support this protocol. Support for TLS 1.1 and above has been supported for over 5 years by newer OpenVPN client versions.

In at attempt to accommodate devices with clients that don't support modern TLS, we have re-enabled TLS 1.0 on beta.vpn.sonic.net. We hope this gives folks time to interface with their hardware vendors to get updated firmware/software that include updated OpenVPN client versions.

In the meantime please try logging in to beta.vpn.sonic.net to download the client config and update your devices to use it instead. We're seeing an overwhelming majority of clients adjusting fine to the protocol upgrade, and very few are failing as a result of still using TLS 1.0. Some clients that support TLS 1.1/1.2 *may* have specific cipher settings preventing them from using a newer protocol. If your OpenVPN client is 2.3.4 or later, ensure the config is not specifying an outdated set of ciphers or is being forced to use TLS 1.0.

On the beta VPN we will continue to support TLS 1.0 for at least 30 days. We hope this helps and that the beta option will be satisfactory. Please keep us updated in regards to the possibility or impossibility of getting updated OVPN support in hardware.

[SonicGuest]

Eventually there will be an update for EdgeOS to v2.0 with a different debian base which will update the OpenVPN client according to this post:

https://community.ubnt.com/t5/EdgeMAX-F ... 6#comments

Until then, looks like using the beta server is the best option unless someone can come up with a workaround.