TransWikia.com

OpenVPN - tun0 sucessfully configured by the service but interface lacks ip or routing configuration

Server Fault Asked by José Neves on November 9, 2021

I’m configuring OpenVPN on a Ubuntu 18.04 client as it follows:

##############################################
# Sample client-side OpenVPN 2.0 config file #
# for connecting to multi-client server.     #
#                                            #
# This configuration can be used by multiple #
# clients, however each client should have   #
# its own cert and key files.                #
#                                            #
# On Windows, you might want to rename this  #
# file so it has a .ovpn extension           #
##############################################

# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client

# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun

# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel
# if you have more than one.  On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
;dev-node MyTap

# Are we connecting to a TCP or
# UDP server?  Use the same setting as
# on the server.
proto tcp
;proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote c 80
;remote my-server-2 1194

# Choose a random host from the remote
# list for load-balancing.  Otherwise
# try hosts in the order specified.
;remote-random

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind

# Downgrade privileges after initialization (non-Windows only)
# user nobody
# group nogroup

# Try to preserve some state across restarts.
persist-key
persist-tun

# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here.  See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]

# Wireless networks often produce a lot
# of duplicate packets.  Set this flag
# to silence duplicate packet warnings.
;mute-replay-warnings

# SSL/TLS parms.
# See the server config file for more
# description.  It's best to use
# a separate .crt/.key file pair
# for each client.  A single ca
# file can be used for all clients.
ca ca.crt
cert client.crt
key client.key

# Verify server certificate by checking that the
# certicate has the correct key usage set.
# This is an important precaution to protect against
# a potential attack discussed here:
#  http://openvpn.net/howto.html#mitm
#
# To use this feature, you will need to generate
# your server certificates with the keyUsage set to
#   digitalSignature, keyEncipherment
# and the extendedKeyUsage to
#   serverAuth
# EasyRSA can do this for you.
remote-cert-tls server

# If a tls-auth key is used on the server
# then every client must also have the key.
tls-auth ta.key 1

# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
# Note that v2.4 client/server will automatically
# negotiate AES-256-GCM in TLS mode.
# See also the ncp-cipher option in the manpage
cipher AES-256-CBC
auth SHA256

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
#comp-lzo

# Set log file verbosity.
verb 3

# Silence repeating messages
;mute 20
key-direction 1

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
<ca>
...
</ca>
<cert>
...
</cert>
<key>
...
<tls-auth>
...
</tls-auth>

openvpn /etc/openvpn/client.conf results into:

Tue Jul 21 15:59:09 2020 us=191135 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2019
Tue Jul 21 15:59:09 2020 us=191150 library versions: OpenSSL 1.1.1  11 Sep 2018, LZO 2.08
Tue Jul 21 15:59:09 2020 us=191222 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Tue Jul 21 15:59:09 2020 us=191609 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Tue Jul 21 15:59:09 2020 us=191634 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Tue Jul 21 15:59:09 2020 us=191721 Control Channel MTU parms [ L:1623 D:1170 EF:80 EB:0 ET:0 EL:3 ]
Tue Jul 21 15:59:09 2020 us=191758 Data Channel MTU parms [ L:1623 D:1450 EF:123 EB:406 ET:0 EL:3 ]
Tue Jul 21 15:59:09 2020 us=191790 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1571,tun-mtu 1500,proto TCPv4_CLIENT,keydir 1,cipher AES-256-CBC,auth SHA256,keysize 256,tls-auth,key-method 2,tls-client'
Tue Jul 21 15:59:09 2020 us=191802 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1571,tun-mtu 1500,proto TCPv4_SERVER,keydir 0,cipher AES-256-CBC,auth SHA256,keysize 256,tls-auth,key-method 2,tls-server'
Tue Jul 21 15:59:09 2020 us=191816 TCP/UDP: Preserving recently used remote address: [AF_INET]c:80
Tue Jul 21 15:59:09 2020 us=191842 Socket Buffers: R=[131072->131072] S=[16384->16384]
Tue Jul 21 15:59:09 2020 us=191855 Attempting to establish TCP connection with [AF_INET]c:80 [nonblock]
Tue Jul 21 15:59:10 2020 us=192033 TCP connection established with [AF_INET]c:80
Tue Jul 21 15:59:10 2020 us=192077 TCP_CLIENT link local: (not bound)
Tue Jul 21 15:59:10 2020 us=192086 TCP_CLIENT link remote: [AF_INET]c:80
Tue Jul 21 15:59:10 2020 us=192940 TLS: Initial packet from [AF_INET]c:80, sid=1262c750 4c7a1222
Tue Jul 21 15:59:10 2020 us=236253 VERIFY OK: depth=1, CN=vpn.xxxxxx.com
Tue Jul 21 15:59:10 2020 us=236402 VERIFY KU OK
Tue Jul 21 15:59:10 2020 us=236422 Validating certificate extended key usage
Tue Jul 21 15:59:10 2020 us=236438 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Tue Jul 21 15:59:10 2020 us=236447 VERIFY EKU OK
Tue Jul 21 15:59:10 2020 us=236455 VERIFY OK: depth=0, CN=vpn.xxxxxx.com
Tue Jul 21 15:59:10 2020 us=241649 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
Tue Jul 21 15:59:10 2020 us=241680 [vpn.xxxxx.com] Peer Connection Initiated with [AF_INET]c:80
Tue Jul 21 15:59:11 2020 us=504067 SENT CONTROL [vpn.xxxxx.com]: 'PUSH_REQUEST' (status=1)
Tue Jul 21 15:59:11 2020 us=506069 PUSH: Received control message: 'PUSH_REPLY,route 10.0.0.0 255.0.0.0,dhcp-option DNS b,dhcp-option DNS a,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.25 10.8.0.26,peer-id 0,cipher AES-256-GCM'
Tue Jul 21 15:59:11 2020 us=506158 OPTIONS IMPORT: timers and/or timeouts modified
Tue Jul 21 15:59:11 2020 us=506174 OPTIONS IMPORT: --ifconfig/up options modified
Tue Jul 21 15:59:11 2020 us=506181 OPTIONS IMPORT: route options modified
Tue Jul 21 15:59:11 2020 us=506192 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue Jul 21 15:59:11 2020 us=506199 OPTIONS IMPORT: peer-id set
Tue Jul 21 15:59:11 2020 us=506206 OPTIONS IMPORT: adjusting link_mtu to 1626
Tue Jul 21 15:59:11 2020 us=506216 OPTIONS IMPORT: data channel crypto options modified
Tue Jul 21 15:59:11 2020 us=506224 Data Channel: using negotiated cipher 'AES-256-GCM'
Tue Jul 21 15:59:11 2020 us=506239 Data Channel MTU parms [ L:1554 D:1450 EF:54 EB:406 ET:0 EL:3 ]
Tue Jul 21 15:59:11 2020 us=506310 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Jul 21 15:59:11 2020 us=506325 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Jul 21 15:59:11 2020 us=506444 ROUTE_GATEWAY 172.31.32.1/255.255.240.0 IFACE=eth0 HWADDR=0a:c3:78:f1:6c:f4
Tue Jul 21 15:59:11 2020 us=506701 TUN/TAP device tun0 opened
Tue Jul 21 15:59:11 2020 us=506738 TUN/TAP TX queue length set to 100
Tue Jul 21 15:59:11 2020 us=506760 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Tue Jul 21 15:59:11 2020 us=506784 /sbin/ip link set dev tun0 up mtu 1500
Tue Jul 21 15:59:11 2020 us=508154 /sbin/ip addr add dev tun0 local 10.8.0.25 peer 10.8.0.26
Tue Jul 21 15:59:11 2020 us=509257 /etc/openvpn/update-resolv-conf tun0 1500 1554 10.8.0.25 10.8.0.26 init
dhcp-option DNS a
dhcp-option DNS b
Too few arguments.
Too few arguments.
Tue Jul 21 15:59:11 2020 us=552185 /sbin/ip route add 10.0.0.0/8 via 10.8.0.26
Tue Jul 21 15:59:11 2020 us=553483 /sbin/ip route add 10.8.0.1/32 via 10.8.0.26
Tue Jul 21 15:59:11 2020 us=554437 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Tue Jul 21 15:59:11 2020 us=554471 Initialization Sequence Completed

One would assume that the process was successful and the client is now connected to the VPN, however, the tun0 interface didn’t acquire IP nor the routes exist.

When that same process exits:

^CTue Jul 21 16:06:19 2020 us=140846 event_wait : Interrupted system call (code=4)
Tue Jul 21 16:06:19 2020 us=141061 TCP/UDP: Closing socket
Tue Jul 21 16:06:19 2020 us=141125 /sbin/ip route del 10.0.0.0/8
RTNETLINK answers: No such process
Tue Jul 21 16:06:19 2020 us=142360 ERROR: Linux route delete command failed: external program exited with error status: 2
Tue Jul 21 16:06:19 2020 us=142395 /sbin/ip route del 10.8.0.1/32
RTNETLINK answers: No such process
Tue Jul 21 16:06:19 2020 us=143403 ERROR: Linux route delete command failed: external program exited with error status: 2
Tue Jul 21 16:06:19 2020 us=143438 Closing TUN/TAP interface
Tue Jul 21 16:06:19 2020 us=143461 /sbin/ip addr del dev tun0 local 10.8.0.25 peer 10.8.0.26
RTNETLINK answers: Cannot assign requested address
Tue Jul 21 16:06:19 2020 us=144445 Linux ip addr del failed: external program exited with error status: 2
Tue Jul 21 16:06:19 2020 us=172551 /etc/openvpn/update-resolv-conf tun0 1500 1554 10.8.0.25 10.8.0.26 init
Too few arguments.
Too few arguments.
Tue Jul 21 16:06:19 2020 us=202598 SIGINT[hard,] received, process exiting

Can’t find the reason for this, other clients work fine.

If ip addr and ip route operations are run manually after service start it all works as it’s supposed too. However, service is unable to recover from disconnection issues for the same reason that didn’t connect automatically.

Syslog:

Jul 22 08:08:35 ip-172-31-32-67 systemd-networkd[7024]: tun0: Link DOWN
Jul 22 08:08:35 ip-172-31-32-67 systemd-networkd[7024]: tun0: Lost carrier
Jul 22 08:08:35 ip-172-31-32-67 systemd-timesyncd[690]: Network configuration changed, trying to establish connection.
Jul 22 08:08:35 ip-172-31-32-67 systemd[1]: Stopping Netscript ifup for tun0...
Jul 22 08:08:35 ip-172-31-32-67 systemd-timesyncd[690]: Synchronized to time server b:123 (ntp.ubuntu.com).
Jul 22 08:08:35 ip-172-31-32-67 netscript[21167]: Usage: netscript ifup|ifdown|ifqos|ifreload
Jul 22 08:08:35 ip-172-31-32-67 netscript[21167]:            {eth0|eth2|eth1|all}
Jul 22 08:08:35 ip-172-31-32-67 systemd[1]: [email protected]: Control process exited, code=exited status=1
Jul 22 08:08:35 ip-172-31-32-67 systemd[1]: [email protected]: Failed with result 'exit-code'.
Jul 22 08:08:35 ip-172-31-32-67 systemd[1]: Stopped Netscript ifup for tun0.
Jul 22 08:08:47 ip-172-31-32-67 systemd-udevd[21286]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jul 22 08:08:47 ip-172-31-32-67 systemd-networkd[7024]: tun0: Link UP
Jul 22 08:08:47 ip-172-31-32-67 networkd-dispatcher[1251]: WARNING:Unknown index 28 seen, reloading interface list
Jul 22 08:08:47 ip-172-31-32-67 systemd-networkd[7024]: tun0: Gained carrier
Jul 22 08:08:47 ip-172-31-32-67 systemd-networkd[7024]: tun0: Gained IPv6LL
Jul 22 08:08:47 ip-172-31-32-67 systemd-timesyncd[690]: Network configuration changed, trying to establish connection.
Jul 22 08:08:47 ip-172-31-32-67 systemd[1]: Unnecessary job for /sys/subsystem/net/devices/tun0 was removed.
Jul 22 08:08:47 ip-172-31-32-67 systemd[1]: Started Netscript ifup for tun0.
Jul 22 08:08:47 ip-172-31-32-67 systemd-timesyncd[690]: Synchronized to time server b:123 (ntp.ubuntu.com).
Jul 22 08:08:47 ip-172-31-32-67 systemd-timesyncd[690]: Network configuration changed, trying to establish connection.
Jul 22 08:08:47 ip-172-31-32-67 systemd-timesyncd[690]: Synchronized to time server b:123 (ntp.ubuntu.com).
Jul 22 08:08:47 ip-172-31-32-67 sh[21324]: Configuring interface:Warning: Executing wildcard deletion to stay compatible with old scripts.
Jul 22 08:08:47 ip-172-31-32-67 sh[21324]:          Explicitly specify the prefix length (10.8.0.25/32) to avoid this warning.
Jul 22 08:08:47 ip-172-31-32-67 sh[21324]:          This special behaviour is likely to disappear in further releases,
Jul 22 08:08:47 ip-172-31-32-67 sh[21324]:          fix your scripts!
Jul 22 08:08:47 ip-172-31-32-67 systemd-timesyncd[690]: Network configuration changed, trying to establish connection.
Jul 22 08:08:47 ip-172-31-32-67 sh[21324]:  tun0.
Jul 22 08:08:47 ip-172-31-32-67 systemd-timesyncd[690]: Synchronized to time server a (ntp.ubuntu.com).

Did anyone else experienced this?

2 Answers

I had an issue, which lead me here on Ubuntu 20.04.2 and fixed that by uninstalling the netscript-2.4 package and installing the package ifupdown instead.

Answered by user619217 on November 9, 2021

So, I get you right, after openvpn startup, you have a tun0 interface without ip? Did you check that the client configuration posted here matches the server configuration ?

A research showed others having the same problem after a network reconnect causing the loss of the ip... caused by option proto none in the interface option configuration file. Reference

If that doesn't help, I would suggest disabling your up / down scripts for a start, those log entries show that this script is definately broken... here is what I mean:

dhcp-option DNS a
dhcp-option DNS b
Too few arguments.
Too few arguments.

And:

Jul 22 08:08:47 ip-172-31-32-67 sh[21324]: Configuring interface:Warning: Executing wildcard deletion to stay compatible with old scripts.
Jul 22 08:08:47 ip-172-31-32-67 sh[21324]:          Explicitly specify the prefix length (10.8.0.25/32) to avoid this warning.
Jul 22 08:08:47 ip-172-31-32-67 sh[21324]:          This special behaviour is likely to disappear in further releases,
Jul 22 08:08:47 ip-172-31-32-67 sh[21324]:          fix your scripts!

Another thing which I noticed, are you really using tcp port 80 for openvpn service ? I would say this is a bad idea...

In the syslog, I noticed the following message:

Jul 22 08:08:35 ip-172-31-32-67 systemd-networkd[7024]: tun0: Link DOWN
Jul 22 08:08:35 ip-172-31-32-67 systemd-networkd[7024]: tun0: Lost carrier

This looks like the main vpn connection ( remote c 80 ) gets lost during vpn setup, for example due to a malicious route being set.

And, just for completeness, Here is the part where the tun0 interface gets its own IP:

Tue Jul 21 15:59:11 2020 us=508154 /sbin/ip addr add dev tun0 local 10.8.0.25 peer 10.8.0.26

I hope I could supply to you a start for research!

Answered by Martin on November 9, 2021

Add your own answers!

Ask a Question

Get help from others!

© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP