What's new

Incoming OpenVPN changes in next release

RMerlin

Asuswrt-Merlin dev
Staff member
I have started working on OpenVPN 2.7 support, and am reviewing some of the changes that came with it. Two important things:

--secret support is now disabled by default. That authentication method is deemed no longer safe, so by default OpenVPN no longer supports it. Unless I can get a good case for it to be kept (it will require manually re-enabling it at compile time), I intend to also fully remove it, in both server and client configurations. Note that secret support will be fully removed in OpenVPN 2.8, so now's as good a time as any for people still using it to modernize their setup.

OpenVPN will no longer send compressed data. Compression has been labeled as deprecated for quite a few years already. Starting with 2.7, OpenVPN can still accept inbound compressed data (probably for backward compatibility) but it will no longer send any compressed data itself. This one I am on the fence as to how to handle. On one hand, it's been labeled as both deprecated and unsafe for many years already by the OpenVPN devs. On the other hand, how many users are still unaware of this, and would enable it thinking it was a good thing to do (even tho the majority of modern traffic is either compressed or pre-encrypted data, so it doesn't really compress well in the tunnel context). Any thoughts?

In any case, both of these will be documented explicitely in the changelog, so router admins will be aware of it before they upgrade (assuming they actually read the changelog - if they don't, then I blame them).

Another noteworthy change is that the subnet topology is now the default. But that's something I already changed many years ago in the default server configuration, so it might only come into effect if someone has a really unusual setup and were using a postconf script to replace "topology subnet" with "topology net30". Now, they would have to just append "topology net30", there won't be any existing config line to modify.
 
Thanks for the updates, @RMerlin. I'd vote to just have compression removed altogether. I'd stick with OpenVPN's reasoning for the change, plus if it only works one way and not the other, that might generate even more confusion for users continuing to want to make use of this functionality.
 
Thanks for the update. I also vote to remove compression; I can’t think of any reason why it would be beneficial to keep it.
 
I haven't used compression on any openvpn access server for years, just kept them at the default disabled. There has been warnings against using compression for years.
Great move 👍🏼
 
I have started working on OpenVPN 2.7 support, and am reviewing some of the changes that came with it. Two important things:

--secret support is now disabled by default. That authentication method is deemed no longer safe, so by default OpenVPN no longer supports it. Unless I can get a good case for it to be kept (it will require manually re-enabling it at compile time), I intend to also fully remove it, in both server and client configurations. Note that secret support will be fully removed in OpenVPN 2.8, so now's as good a time as any for people still using it to modernize their setup.

OpenVPN will no longer send compressed data. Compression has been labeled as deprecated for quite a few years already. Starting with 2.7, OpenVPN can still accept inbound compressed data (probably for backward compatibility) but it will no longer send any compressed data itself. This one I am on the fence as to how to handle. On one hand, it's been labeled as both deprecated and unsafe for many years already by the OpenVPN devs. On the other hand, how many users are still unaware of this, and would enable it thinking it was a good thing to do (even tho the majority of modern traffic is either compressed or pre-encrypted data, so it doesn't really compress well in the tunnel context). Any thoughts?

In any case, both of these will be documented explicitely in the changelog, so router admins will be aware of it before they upgrade (assuming they actually read the changelog - if they don't, then I blame them).

Another noteworthy change is that the subnet topology is now the default. But that's something I already changed many years ago in the default server configuration, so it might only come into effect if someone has a really unusual setup and were using a postconf script to replace "topology subnet" with "topology net30". Now, they would have to just append "topology net30", there won't be any existing config line to modify.
Remove support for compression. Hasn't been used/supported for a number of years by my VPN provider.
 
Remove support for compression. Hasn't been used/supported for a number of years by my VPN provider.
All tunnel providers should have disabled compression many years ago. My concern is more for the server config, where some people might have enabled it for remote access without being aware of the feature deprecation. But I think that if it gets documented in the changelog, they will have ample opportunity to correct that before updating (if they somehow do remote updates - always a bad idea), or right after updating.

Another potential issue is people who configure a client to connect to a remote server. I know for instance that QNAP used to have compression enabled by default, so older QVPN setups might still expect clients to connect with compression enabled.

One compromise I might make then is to remove it from the server, but leave it in place for clients. I took the same approach years ago when I removed unsecure ciphers from the server, but left it there for clients. That way, the router server (which is entirely under the router owner's control) can be made more secure, while clients that may need to connect to outdated servers will continue to work.
 
Any feedback on the (albeit obscure) static key auth method? I already removed it from the server code, I am debating removing it from the client code as well considering how obscure (and much less secure than regular tls auth) it is. Personmally, I don't remember having ever seen it deployed.
 
Any feedback on the (albeit obscure) static key auth method? I already removed it from the server code, I am debating removing it from the client code as well considering how obscure (and much less secure than regular tls auth) it is. Personmally, I don't remember having ever seen it deployed.
Meh. (I think that says it all). 😉
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Back
Top