ip addr add not taking effect

[jonatan.olofsson]

Not sure if installation, configuration or bug report...

I am installing OpenVPN for the first time, so I may of course have missed something, but..

When my (linux) client connects to the vpn, it connects successfully with the following output:

Code: Select all

Fri Feb  2 17:20:29 2018 PUSH: Received control message: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,compress lz4-v2,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.4 255.255.255.0,peer-id 0,cipher AES-256-GCM'
Fri Feb  2 17:20:29 2018 OPTIONS IMPORT: timers and/or timeouts modified
Fri Feb  2 17:20:29 2018 OPTIONS IMPORT: compression parms modified
Fri Feb  2 17:20:29 2018 OPTIONS IMPORT: --ifconfig/up options modified
Fri Feb  2 17:20:29 2018 OPTIONS IMPORT: route options modified
Fri Feb  2 17:20:29 2018 OPTIONS IMPORT: route-related options modified
Fri Feb  2 17:20:29 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Feb  2 17:20:29 2018 OPTIONS IMPORT: peer-id set
Fri Feb  2 17:20:29 2018 OPTIONS IMPORT: adjusting link_mtu to 1625
Fri Feb  2 17:20:29 2018 OPTIONS IMPORT: data channel crypto options modified
Fri Feb  2 17:20:29 2018 Data Channel: using negotiated cipher 'AES-256-GCM'
Fri Feb  2 17:20:29 2018 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Fri Feb  2 17:20:29 2018 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Fri Feb  2 17:20:29 2018 ROUTE_GATEWAY 192.168.43.1/255.255.255.0 IFACE=wlp3s0 HWADDR=ac:bc:32:af:1b:bd
Fri Feb  2 17:20:29 2018 TUN/TAP device tun0 opened
Fri Feb  2 17:20:29 2018 TUN/TAP TX queue length set to 100
Fri Feb  2 17:20:29 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Fri Feb  2 17:20:29 2018 /usr/bin/ip link set dev tun0 up mtu 1500
Fri Feb  2 17:20:29 2018 /usr/bin/ip addr add dev tun0 10.8.0.4/24 broadcast 10.8.0.255
Fri Feb  2 17:20:29 2018 /usr/bin/ip route add a.b.c.d/32 via 192.168.43.1
RTNETLINK answers: File exists
Fri Feb  2 17:20:29 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Fri Feb  2 17:20:29 2018 /usr/bin/ip route add 0.0.0.0/1 via 10.8.0.1
Fri Feb  2 17:20:29 2018 /usr/bin/ip route add 128.0.0.0/1 via 10.8.0.1
Fri Feb  2 17:20:29 2018 /usr/bin/ip route add 192.168.0.0/24 via 10.8.0.1
Error: Nexthop has invalid gateway.
Fri Feb  2 17:20:29 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Fri Feb  2 17:20:29 2018 GID set to nobody
Fri Feb  2 17:20:29 2018 UID set to nobody
Fri Feb  2 17:20:29 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Feb  2 17:20:29 2018 Initialization Sequence Completed

The RTNETLINK error is (i gather) that that rule already exists, i.e. no harm in that error. The second error is "Error: Nexthop has invalid gateway.", which I will get back to below.

Even though the connection ends in "Initialization Sequence Completed", I quickly notice that I cant ping the server (10.8.0.1, config below), and that the vpn generally doesn't work. Looking at the ip route:

Code: Select all

# ip route show
default via 192.168.43.1 dev wlp3s0 proto dhcp src 192.168.43.43 metric 1024 
a.b.c.d via 192.168.43.1 dev wlp3s0 
192.168.43.0/24 dev wlp3s0 proto kernel scope link src 192.168.43.43 
192.168.43.1 dev wlp3s0 proto dhcp scope link src 192.168.43.43 metric 1024 

and addresses

Code: Select all

# ip addr show
...
21: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 
    inet6 fe80::ec3c:2ec7:a5ec:5015/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

I.e. the tun0 has not received neither ip nor routes. Of course, manually adding the routes yields the same "Error: Nexthop has invalid gateway." as above, as the ip needs to be set first. Manually executing the "ip addr add" command from the openvpn output finishes successfully, and after also manually adding the routes (which now works, since the ip is defined), the vpn connection is all up and running.

It thus seems that the ip addr add command takes no effect and the subsequent errors follow from that. The question now is, am I doing something wrong or is this a bug?

Client config:

Code: Select all

client
dev tun
proto udp
remote ***** ***
nobind
user nobody
group nobody
persist-key
persist-tun
remote-cert-tls server
tls-auth ta.key 1
key-direction 1
cipher AES-256-CBC 
auth SHA512 
tls-version-min 1.2 
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA 
compress lz4-v2
push "compress lz4-v2"
verb 3

Server config:

Code: Select all

port 443
proto udp
dev tun
ca ca.crt
cert nanoheart.crt
key nanoheart.key  # This file should be kept secret
dh dh2048.pem
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.0.0 255.255.255.0"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120
tls-auth ta.key 0 # This file is secret
key-direction 0
cipher AES-256-CBC
auth SHA512
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
compress lz4-v2
push "compress lz4-v2"
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
explicit-exit-notify 1

Client version:

Code: Select all

$ openvpn --version
OpenVPN 2.4.4 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 26 2017
library versions: OpenSSL 1.1.0g  2 Nov 2017, LZO 2.10
Originally developed by James Yonan
Copyright (C) 2002-2017 OpenVPN Technologies, Inc. <sales@openvpn.net>
Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_iproute2=yes enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_management=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_werror=no enable_win32_dll=yes enable_x509_alt_username=yes with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no

Server version:

Code: Select all

OpenVPN 2.4.3 aarch64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul  3 2017
library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 2.08
Originally developed by James Yonan
Copyright (C) 2002-2017 OpenVPN Technologies, Inc. <sales@openvpn.net>
Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=yes enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_maintainer_mode=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_silent_rules=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_werror=no enable_win32_dll=yes enable_x509_alt_username=yes with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no

[kuklinistvan]

Hey there!

Looks like I'm having exactly the same issue - manually executing the failed ip commands work but strangely these commands do no take effect at connecting. Also, manually running them one by one is quite tedious, especially if I have a lot of routes to add. I have these invalid Nexthops as well.

I have experienced this with my own server and with an external provider too - actually, I have no working configuration at the moment.

I'm running Arch Linux and OpenVPN version 2.4.5.

Did you manage to find a solution for this problem since then?

[system.shock]

More information about this issue:
https://www.reddit.com/r/archlinux/comm ... my_tunnel/
https://forums.gentoo.org/viewtopic-t-1 ... ight-.html

I find that when i am running:

Code: Select all

ltrace openvpn --config /etc/openvpn/client/client.conf

Ip address added successfully everytime. Sounds crazy but that works.
Is this a bug which hasn't been reported yet?

[TinCanTech]

This was reported more than two years ago and the version of OpenVPN was six months older than that.

I use Arch and have never encountered this problem.

The problem is definitely caused by the ip address on the tun device being missing, however, at the time which openvpn configures the ip address the OS ip command does not report an error.

I further bug report was made here:
https://community.openvpn.net/openvpn/ticket/1086

The bug report seems to suggest that systemd-networkd is responsible.

Further testing on the effected systems with an upto date version of openvpn would be interesting.