# OpenVPN 2.6 Development version

**URL:** <https://community.ipfire.org/t/openvpn-2-6-development-version/8603>\
**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:** 5\
**Page:** 1

<div class="post-metadata">

**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:** [19 September 2022 16:12 UTC](https://community.ipfire.org/t/openvpn-2-6-development-version/8603/1 "2022-09-19T16:12:48Z")

</div>

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](https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn26) is not that far may some people are looking into this ?

Best,

Erik

EDIT: Update to 2.6 is meanwhile out [openvpn/Changes.rst at master · OpenVPN/openvpn · GitHub](https://github.com/OpenVPN/openvpn/blob/master/Changes.rst)

---

<div class="post-metadata">

**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\
**Post date:** [31 January 2023 12:34 UTC](https://community.ipfire.org/t/openvpn-2-6-development-version/8603/2 "2023-01-31T12:34:19Z")

</div>

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.

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.

---

<div class="post-metadata">

**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")

</div>

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

```

?

---

<div class="post-metadata">

**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:** [3 March 2023 08:45 UTC](https://community.ipfire.org/t/openvpn-2-6-development-version/8603/4 "2023-03-03T08:45:45Z")

</div>

According to the new OpenVPN feature “[Data Channel Offload (aka OVPN-DCO)](https://community.openvpn.net/openvpn/wiki/DataChannelOffload)” 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](https://github.com/OpenVPN/openvpn/blob/master/README.dco.md#dco-and-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](https://community.openvpn.net/openvpn/wiki/Topology) .

It might be interesting to check the general limitations which can be found in here → [openvpn/README.dco.md at master · OpenVPN/openvpn · GitHub](https://github.com/OpenVPN/openvpn/blob/master/README.dco.md#limitations-by-design) .

Have compiled a first testing ISO which includes OpenSSL-3.0.8 (which fixes also [CVE-2023-0401](https://www.cve.org/CVERecord?id=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](https://lists.ipfire.org/pipermail/development/2023-February/015450.html) . All changes in this ISO can be found in here → [git.ipfire.org Git - people/ummeegge/ipfire-2.x.git/commit](https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=5f85ecb7b26628fccbed65c08b54e35c7f249ee5) and the ISO is located in here → [Index of /~ummeegge](https://people.ipfire.org/~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…

---

<div class="post-metadata">

**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:** [21 March 2024 13:09 UTC](https://community.ipfire.org/t/openvpn-2-6-development-version/8603/5 "2024-03-21T13:09:50Z")

</div>

Hi all,  
have made meanwhile a first step for an update to OpenVPN-2.6.9 . Which includes now the needed [NCP](https://community.openvpn.net/openvpn/wiki/CipherNegotiation) 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](https://people.ipfire.org/~ummeegge/OpenVPN-2.6.9%20-%20All%20files/) .

For installation details, please consult the README file → [https://people.ipfire.org/~ummeegge/OpenVPN-2.6.9%20-%20All%20files/README](https://people.ipfire.org/~ummeegge/OpenVPN-2.6.9%20-%20All%20files/README) in the same directory.

All changes can be found in Patchwork → [IPFire - Patchwork](https://patchwork.ipfire.org/project/ipfire/list/?series=4230) .

All the best,

Erik

P.S.: @bonnietwin , you can build it also by yourself but for a fast overview, have upload the files especially for you, may it saves time.

Current state:

 ![ovpn_cipher-fallback_ser2](https://community.ipfire.org/uploads/default/original/2X/1/1067821d6a8265d38294c5cd933a1688a93e8d7d.png)