You are not logged in.
Some months ago I ran into an issues with OpenVPN server. It stopped assigning an ip4 address to a freshly brought up tun0 interface. Note that I didn't change config file in a couple of years, and the server has been working as intended prior to this issue. Attaching a snippet of the long after
# systemctl start openvpn-server@archer.service# journalctl -u openvpn-server@archer.service
Aug 05 19:45:18 archer systemd[1]: Started OpenVPN service for archer.
Aug 05 19:45:18 archer openvpn[25856]: OpenVPN 2.4.7 [git:makepkg/2b8aec62d5db2c17+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 19 2019
Aug 05 19:45:18 archer openvpn[25856]: library versions: OpenSSL 1.1.1c 28 May 2019, LZO 2.10
Aug 05 19:45:18 archer openvpn[25856]: Diffie-Hellman initialized with 2048 bit key
Aug 05 19:45:18 archer openvpn[25856]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 05 19:45:18 archer openvpn[25856]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 05 19:45:18 archer openvpn[25856]: TLS-Auth MTU parms [ L:1622 D:1184 EF:66 EB:0 ET:0 EL:3 ]
Aug 05 19:45:18 archer openvpn[25856]: TUN/TAP device tun0 opened
Aug 05 19:45:18 archer openvpn[25856]: TUN/TAP TX queue length set to 100
Aug 05 19:45:18 archer openvpn[25856]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Aug 05 19:45:18 archer openvpn[25856]: /usr/bin/ip link set dev tun0 up mtu 1500
Aug 05 19:45:18 archer openvpn[25856]: /usr/bin/ip addr add dev tun0 192.168.73.1/24 broadcast 192.168.73.255
Aug 05 19:45:18 archer openvpn[25856]: Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
Aug 05 19:45:18 archer openvpn[25856]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Aug 05 19:45:18 archer openvpn[25856]: UDPv4 link local (bound): [AF_INET][undef]:1194
Aug 05 19:45:18 archer openvpn[25856]: UDPv4 link remote: [AF_UNSPEC]
Aug 05 19:45:18 archer openvpn[25856]: GID set to nobody
Aug 05 19:45:18 archer openvpn[25856]: UID set to nobody
Aug 05 19:45:18 archer openvpn[25856]: MULTI: multi_init called, r=256 v=256
...
Aug 05 19:45:18 archer openvpn[25856]: Initialization Sequence CompletedAlthough ip command is supposedly executed, I do not see address assignment
% ip addr show dev tun0
7: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
link/none
inet6 fe80::7782:d0d2:482b:7aa5/64 scope link stable-privacy
valid_lft forever preferred_lft foreverExecuting the command from the log manually, I get the desired result
# /usr/bin/ip addr add dev tun0 192.168.73.1/24 broadcast 192.168.73.255
% ip addr show dev tun0
7: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
link/none
inet 192.168.73.1/24 brd 192.168.73.255 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::7782:d0d2:482b:7aa5/64 scope link stable-privacy
valid_lft forever preferred_lft foreverAfter which VPN server works as intended.
Setting log verbosity in server configuration to 6 didn't show any extra information around address assignment command in the log. Setting verbosity to 9, systemd log suppressed log output.
My questions are:
Why there is IP6 address assigned for tun0 and not ip4? BTW, there is no mentioning of ip6 in my configuration file.
Is there any place I can see the result of address assignment command, and continue debugging my server?
Any help is greatly appreciated.
Offline
Did you ever resolve this? I suspect I'm having the same problem you are.
Offline
It looks like this has been a longstanding problem across multiple distributions. Here's a workaround:
https://github.com/kylemanna/docker-ope … -379465141
Offline
Yes, I did!
In my case the problem was with competing network management. Because my Linux box is intended to be headless, the network is managed using systemd-networkd. Even though I didn't have any implicit configuration for tun0 (my OpenVPN network interface), it has still assumed a full authority over its configuration. Therefore, when OpenVPN needed to set up the interface and the address, nothing really happened. Restarting OpenVPN after boot didn't lead to a success.
The trick was to disable tun0 management from systemd-networkd. One way to accomplish it is to create a file /etc/systemd/network/90-tun-ignore.network that contains the following
[Match]
Name=tun*
[Link]
Unmanaged=trueOffline
BTW, it was in Arch Wiki OpenVPN troubleshooting section. However, in my case it manifested not in Route configuration failure, but in the entire interface not set up correctly.
Offline
Huh, fascinating. I'll give the same workaround a try and see if that works too. I saw that in the troubleshooting guide but as I never saw that error in my log I glossed right over it. Thanks!
Offline