TUN: adding address failed using service: Element not found

Virtual Private Networks OpenVPN
1

I get this error on a Windows 10 client when trying to connect to IPFire:

MANAGEMENT: >STATE:1675076235,ASSIGN_IP,,10.119.127.14,,,,
INET address service: add 10.119.127.14/30
TUN: adding address failed using service: Element nicht gefunden.   [status=1168 if_index=126]
IPv4 dns servers set using service
TUN: setting IPv4 mtu using service failed: Element nicht gefunden.   [status=1168 if_index=126]
Block_DNS: adding block dns filters using service failed: Element nicht gefunden.   [status=0x490 if_index=126]
MANAGEMENT: Client disconnected

This also seems to stop the “OpenVPN Interactive Service”.

When I edit the client’s config file and change “cipher AES-256-CBC” to “data-ciphers-fallback AES-256-CBC”, the problem is gone and the client is able to connect.

IPv4 only.
OpenVPN settings on IPFire 2.27 (x86_64) - Core-Update 171:
Hash: SHA2 (512 bit)
Encr: AES-CBC (256 bit)

Recently switched to OpenVPN 2.6 but this also happened with 2.5 before (just didn’t investigate further). Initially, I changed “–cipher” to circumvent this warning:

# DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM).
# Future OpenVPN version will ignore --cipher for cipher negotiations.
# Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.

So, I currently have no problem, but I guess others might find this useful (as I couldn’t find anything helpful). Also, maybe the defaults in IPFire should be changed - or have been changed already and my installation is still using the old default values.

2

This is very likely due to your windows client having upgraded to OpenSSL-3.x

IPFire is still running with the OpenSSL-1.1.1 series, which is still being supported with security and bug fix etc updates.

However there is a mismatch between the ciphers accepted by the two versions of OpenSSL.

I believe if you add the line
providers legacy default
to your .ovpn file it should fix the problem. This option is only available from openvpn-2.6.0

See thread New OpenVPN 2.6.0 Client (Windows 10 64bit) fails to connect

Alternatively you can modify the openssl.cnf file on your windows client to allow legacy clients.

See thread OVPN Cert creation algo
This thread is covering linux but the pribiple should also work for windows, you would just need to find where the openssl.cnf file is stored and edit it in a similar way as descirbed for the Linux clients.

3

Wanted to mention this in my first post: I have already patched ovpnmain.cgi for new connections and have also fixed my cert to be usable with OpenVPN 2.6.

4

Hi all,

me too, interested in info exchange → OpenVPN 2.6 Development version ?

5

I guess the client’s config file that can be downloaded in the GUI is created on the fly, isn’t it?
Where is the template that is used for that file?

I need to patch this to use the aforementioned “data-ciphers-fallback” as else I would have to do this manually for every new client.

6

Turns out the code isn’t using a template:

print CLIENTCONF "cipher $vpnsettings{DCIPHER}\r\n";

Guess I will have to switch the OpenVPN server setting from “AES-CBC (256 bit)” to “AES-GCM (256 bit)” and probably will have to update every client config.

7

Hi @larsen,

the “template” is the settings file for global configuration and ovpnconfig for client specifics (N2N also global).
According to your configuration update to every client, i did some test in here where it was not needed if the server uses the “–data-ciphers” directive. This is also true for OpenVPN server since version >=2.4.0 .

Best,

Erik

8

Should a recent IPFire installation have “data-ciphers” instead of “cipher”? If not, should I change it?

# egrep "cipher|ncp" /var/ipfire/ovpn/server.conf
ncp-disable
cipher AES-256-CBC
9

Can´t say if you should or should not since i do not have the topic problem. The main reason why i wrote you was to deliver an may more efficient way to solve this.
The recent IPFire installation does NOT have “–data-ciphers” or in this case NCP.

Since a test by only changing the directive in server.conf might be not a huge thing for you and can deliver results according to the problem it might be a good idea ?! but it will be overwritten if you press the “Save” button in WUI or if the WUI get´s an update which will come with the next Core release.

Best,

Erik

10

Ok, I thought maybe our IPFire installation was using old defaults that did no longer exist in a current installation and therefore should be changed.

As for the mentioned side effects, I prefer to not change the default server.conf.
Thanks anyway for the idea.