OpenVPN server does not start properly on boot
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openvpn (Ubuntu) |
Triaged
|
Medium
|
Unassigned | ||
systemd (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
OpenVPN intermittently fails to bind to local address during boot on Ubuntu Server 16.04.2 LTS. Sometimes it succeeds, sometimes it does not.
/var/log/
Wed May 10 15:42:02 2017 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Feb 2 2016
Wed May 10 15:42:02 2017 library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
Wed May 10 15:42:02 2017 Diffie-Hellman initialized with 2048 bit key
Wed May 10 15:42:02 2017 Control Channel Authentication: using './easy-
Wed May 10 15:42:02 2017 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed May 10 15:42:02 2017 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed May 10 15:42:02 2017 Socket Buffers: R=[212992->212992] S=[212992->212992]
Wed May 10 15:42:02 2017 TCP/UDP: Socket bind failed on local address [AF_INET]
Wed May 10 15:42:02 2017 Exiting due to fatal error
In case it does not start, running 'sudo service openvpn start' fixes that problem.
/var/log/
Wed May 10 15:42:43 2017 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Feb 2 2016
Wed May 10 15:42:43 2017 library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
Wed May 10 15:42:43 2017 Diffie-Hellman initialized with 2048 bit key
Wed May 10 15:42:43 2017 Control Channel Authentication: using './easy-
Wed May 10 15:42:43 2017 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed May 10 15:42:43 2017 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed May 10 15:42:43 2017 Socket Buffers: R=[212992->212992] S=[212992->212992]
Wed May 10 15:42:43 2017 ROUTE_GATEWAY 192.168.
Wed May 10 15:42:43 2017 TUN/TAP device tun0 opened
Wed May 10 15:42:43 2017 TUN/TAP TX queue length set to 100
Wed May 10 15:42:43 2017 do_ifconfig, tt->ipv6=0, tt->did_
Wed May 10 15:42:43 2017 /sbin/ip link set dev tun0 up mtu 1500
Wed May 10 15:42:43 2017 /sbin/ip addr add dev tun0 local 172.16.1.1 peer 172.16.1.2
Wed May 10 15:42:43 2017 /sbin/ip route add 172.16.1.0/24 via 172.16.1.2
Wed May 10 15:42:43 2017 GID set to nogroup
Wed May 10 15:42:43 2017 UID set to nobody
Wed May 10 15:42:43 2017 UDPv4 link local (bound): [AF_INET]
Wed May 10 15:42:43 2017 UDPv4 link remote: [undef]
Wed May 10 15:42:43 2017 MULTI: multi_init called, r=256 v=256
Wed May 10 15:42:43 2017 IFCONFIG POOL: base=172.16.1.4 size=62, ipv6=0
Wed May 10 15:42:43 2017 IFCONFIG POOL LIST
Wed May 10 15:42:43 2017 Initialization Sequence Completed
My guess is that systemd starts OpenVPN too early before the network is brought up sufficiently. Running 'sudo systemctl edit --full openvpn' and adding 'Wants=
user@server:~$ sudo systemd-analyze critical-chain
graphical.target @2.160s
└─multi-user.target @2.159s
└─ntp.service @2.054s +104ms
└─remote-
└
The boot time is quite short. Clean install with the additional packages ntp and openssh-server. This happens both on bare metal and as a Virtual Machine (KVM) as well.
/etc/openvpn/
local 192.168.4.254
port 1194
proto udp
dev tun
ca ./easy-
cert ./easy-
key ./easy-
dh ./easy-
tls-auth ./easy-
server 172.16.1.0 255.255.255.0
ifconfig-
push "route 192.168.0.0 255.255.255.0"
push "route 192.168.4.0 255.255.255.0"
keepalive 10 120
comp-lzo
max-clients 5
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log-append /var/log/
verb 3
/etc/network/
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto ens3
iface ens3 inet static
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
# The secondary network interface
auto ens4
iface ens4 inet static
address 192.168.4.254
netmask 255.255.255.0
network 192.168.4.0
broadcast 192.168.4.255
gateway 192.168.4.1
user@server:~$ sudo apt-cache policy openvpn
openvpn:
Installed: 2.3.10-1ubuntu2
Candidate: 2.3.10-1ubuntu2
Version table:
*** 2.3.10-1ubuntu2 500
500 http://
100 /var/lib/
user@server:~$ sudo apt-cache policy systemd
systemd:
Installed: 229-4ubuntu17
Candidate: 229-4ubuntu17
Version table:
*** 229-4ubuntu17 500
500 http://
100 /var/lib/
229-4ubuntu10 500
500 http://
229-4ubuntu4 500
500 http://
description: | updated |
Changed in openvpn (Ubuntu): | |
importance: | Undecided → Medium |
tags: | added: network-online-ordering |
Thank you for reporting this bug. I will add it to the server team backlog, as it does appear to be a real issue.