Hi all,
wanted to ask into the round if there are some people interested into the OpenVPN-2.6.x development ? Since the release data of a milestone version jump → https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn26 is not that far may some people are looking into this ?
Version 2.6.0 seems to be coming to the breakage point for IPFire unless I am have misunderstood some of the changelog.
ncp-disable, which is currently used in the IPFire client connection configuration is completely removed in 2.6.0 also Openssl-3.x is configured making many old ciphers no longer supported. That would stop OpenVPN with any 64 bit ciphers that people still might be using.
That would break their OpenVPN connections, which is not a good idea, even if we think they shouldn’t run with such weak and insecure ciphers. Not sure how many people would still be using them. Not easy to find out.
The fix for that would be to add a legacy option into the client .ovpn file, however that is not something that could be done automatically as part of a Core Update. This would mean that at a Core Update anyone using the now blocked ciphers would have to go and modify all their client connections before they do a CU
I know that this has been a big discussion point in the past about not breaking peoples existing connection configurations with a CU but it seems to me that openvpn-2.6.0 will cause that to happen if we move to it. I can’t see a way around it, unless you have figured something out.
I have added the topic of openvpn-2.6.0 to the agenda of the next developers conf call.
Hello @bonnietwin,
try to make the answer as detailed and short as possible…
According to ‘–ncp-disable’ you are right this directive has been removed and need to be replaced wit ‘–data-ciphers’ on IPFire´s server.conf.
OpenVPN is OpenSSL-3.x ready but OpenVPN itself does NOT exclude 64 bit block ciphers, OpenSSL does it with the default configuration. If you use the legacy mode you will be able to use them also with OpenVPN-2.6.x on IPFire.
OpenVPN 2.5.8 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Nov 1 2022
library versions: OpenSSL 3.0.5 5 Jul 2022, LZO 2.10
If a client uses ‘–cipher BF-CBC’ but IPFire OpenVPN server uses ‘–data-ciphers ChaCha20-Poly1305:AES-256-GCM’
you get a warning on server side with
Jan 31 15:16:01 ipfire-prime openvpnserver[7424]: WARNING: --topology net30 support for server configs with IPv4 pools will be removed in a future release. Please migrate to --topology subnet as soon as possible.
Jan 31 15:16:01 ipfire-prime openvpnserver[7424]: DEPRECATED OPTION: --cipher set to 'BF-CBC' but missing in --data-ciphers (ChaCha20-Poly1305:AES-256-GCM). OpenVPN ignores --cipher for cipher negotiations.
and on client side:
2023-01-31 15:19:33 us=228946 DEPRECATED OPTION: --cipher set to 'BF-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'BF-CBC' to --data-ciphers or change --cipher 'BF-CBC' to --data-ciphers-fallback 'BF-CBC' to silence this warning.
but the connection comes up and AES-GCM will be used →
Jan 31 15:19:40 ipfire-prime openvpnserver[7425]: testNewone/192.168.1.5:40723 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jan 31 15:19:40 ipfire-prime openvpnserver[7425]: testNewone/192.168.1.5:40723 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
You can silence the warning on server side with ‘–data-ciphers-fallback BF-CBC’ and as before ‘’–data-ciphers ChaCha20-Poly1305:AES-256-GCM’
but on client side if no changes has been made it appears again →
2023-01-31 15:19:33 us=228946 DEPRECATED OPTION: --cipher set to 'BF-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'BF-CBC' to --data-ciphers or change --cipher 'BF-CBC' to --data-ciphers-fallback 'BF-CBC' to silence this warning.
i think AEAD is since OpenSSL-1.0.1 available and most of the clients out there should uses >= !!! In my humble opinion, this problem should be semantics in the configuration file not a technical one if NCP is in usage?!
It might be good to check NCP since the cipher negotiation will ignore old deprecated ciphers like DES* or Blowfish, … if the data-ciphers has been set. Nevertheless, under specific circumstances you will find warnings like
WARNING: INSECURE cipher (BF-CBC) with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Support for these insecure ciphers will be removed in OpenVPN 2.7.
so the clock runs but the clock also runs on other topics since ‘–topology net30’ is also deprecated and should be replaced with ‘–topology subnet’ which seems to be a bigger task for a little more far future and the usage of OpenVPN-2.7.x .
Great
According to the backwards compatibility of the old ‘–cipher’ directive on client configuration files, haven´t checked the new ‘–compat-mode version’ → openvpn which can be used on server side, may there is a way to make it more easy also with OpenVPN-2.7 ?
I leave the discussion about DCO for the first out of here.
Hope this helps for the first.
Best,
Erik
P.S.: openvpnctrl seems not to close the socket after a reboot
Jan 31 15:54:38 ipfire-prime openvpnserver[3720]: TCP/UDP: Socket bind failed on local address [AF_INET][undef]:1194: Address already in use (errno=98)
Jan 31 15:54:38 ipfire-prime openvpnserver[3720]: Exiting due to fatal error
Jan 31 15:54:38 ipfire-prime openvpnserver[3720]: Closing TUN/TAP interface
Jan 31 15:54:38 ipfire-prime openvpnserver[3720]: net_addr_ptp_v4_del: 10.73.104.1 dev tun1
According to the new OpenVPN feature “Data Channel Offload (aka OVPN-DCO)” and how it can be used with a potential IPFire update i want to bring something up in here.
ovpn-dco can be used in P2P mode so IPFire´s Net-to-Net connections are supported by this feature since N2N uses thre P2P topology.
Since IPFire´s Roadwarrior uses --topology net30 but ovpn-dco needs a running --topology subnet it won´t work with the current OpenVPN Roadwarrior implementation on IPFire. To fix this, the CCD setup for --ifconfig-push needs changes in the address definitions → https://community.openvpn.net/openvpn/wiki/Topology .
Have compiled a first testing ISO which includes OpenSSL-3.0.8 (which fixes also CVE-2023-0401) , ovpn-dco-0.1.20230206 and OpenVPN-2.6.0 . This ISO does NOT include needed ovpnmmain.cgi changes which can be found in the mailinglist → OpenVPN patchset from Erik's input . All changes in this ISO can be found in here → git.ipfire.org Git - people/ummeegge/ipfire-2.x.git/commit and the ISO is located in here → Index of /~ummeegge if someone wants to give it a testing round in a VM. Have NOT tested it myself since time is currently a little rare.
Best,
Erik
EDIT: ovpn-dco module should be loaded via openvpnctrl.c like the tun module. All dependencies are resolved with ‘ip6_udp_tunnel’ and ‘udp_tunnel’. Git link has been adapted and new ISO is available under above address…
Hi all,
have made meanwhile a first step for an update to OpenVPN-2.6.9 . Which includes now the needed NCP but uses also the “–data-ciphers-fallback” directive to stay compatible with already existing clients until 2.3.x . Since the “–cipher” directive is deprecated since OpenVPN-2.5.0 there was the need to substitute it with this one.
With this patch, new clients needs to be at least at OpenVPN version 2.5.0 cause earlier version won´t understand the NCP configuration semantics cause ‘–cipher’ won´t be used for new clients anymore.
A new cipher called “CHACHA20-POLY1305” has been introduced with this version and can currently only be used with Roadwarriors .
If someone is interested to go into some testing scenarios and deliver feedback or possible enhancements, all files can be found in here → Index of /~ummeegge/OpenVPN-2.6.9 - All files .