# OpenVPN 2.6 Development version **URL:** \ **Category:** OpenVPN\ **Created:** [19 September 2022 16:12 UTC](https://community.ipfire.org/t/openvpn-2-6-development-version/8603 "2022-09-19T16:12:48Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![ummeegge](https://community.ipfire.org/user_avatar/community.ipfire.org/ummeegge/32/16602_2.png) [@ummeegge](https://community.ipfire.org/u/ummeegge)\ **Post date:** [31 January 2023 15:47 UTC](https://community.ipfire.org/t/openvpn-2-6-development-version/8603/3 "2023-01-31T15:47:29Z")
Hello @bonnietwin, try to make the answer as detailed and short as possible… > [@bonnietwin](#): > > Hi @ummeegge > > 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. 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](https://community.ipfire.org/t/ovpn-cert-creation-algo/7911/18) you will be able to use them also with OpenVPN-2.6.x on IPFire. > [@bonnietwin](#): > > 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 Some tests from my side: OpenVPN on IPFire runs: ```bash OpenVPN 2.6.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] [DCO] library versions: OpenSSL 1.1.1s 1 Nov 2022, LZO 2.10 ``` Client Fedora 37 (Workstation Edition) with: ```bash 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 ```bash 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: ```bash 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 → ```bash 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 → ```bash 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?! So a WUI solution like this → ![data-channel_fallback_old_cipher__Patch2_](https://community.ipfire.org/uploads/default/original/2X/1/19532e2366d07dfa749cef255cb82b49014294c8.png) comes for me to mind. > [@bonnietwin](#): > > 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. It might be good to check [NCP](https://community.openvpn.net/openvpn/wiki/CipherNegotiation) 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 ```bash 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 . > [@bonnietwin](#): > > I have added the topic of openvpn-2.6.0 to the agenda of the next developers conf call. Great 👍 According to the backwards compatibility of the old ‘–cipher’ directive on client configuration files, haven´t checked the new ‘–compat-mode version’ → [openvpn](https://build.openvpn.net/man/openvpn-2.6/openvpn.8.html) 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](https://openvpn.net/blog/openvpn-data-channel-offload/) 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 ```bash 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 ``` ? --- _[View the full topic](https://community.ipfire.org/t/openvpn-2-6-development-version/8603)._