OpenVPN TUN interface loses IP address after WAN reconnect

[michael.uray]

Hi guys,

I am running an OpenVPN 2.4.4 on a LEDE Reboot (17.01.4, r3560-79f57e422d) in a Windows 10 Hyper-V container.
The machine has two Ethernet interfaces (LAN / WAN) which are connected to the LEDE system.

There is an OpenVPN client on the LEDE system which connects to an external server.
If I disconnect the WAN cable to the PC for a few seconds and reconnect it, then the tun interface loses its IP addresses during the OpenVPN reconnect and it never will get one assigned.

Before the WAN disconnect:

Code: Select all

tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.102.0.114  P-t-P:10.102.0.113  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:1030 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1304 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:47879 (46.7 KiB)  TX bytes:123341 (120.4 KiB)

After the WAN dis- and re-connect

Code: Select all

tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:2230 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3419 errors:0 dropped:12 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:104279 (101.8 KiB)  TX bytes:276875 (270.3 KiB)

In this situation I have to restart the OpenVPN service to get again an IP address.

This is a part of the log file when the client reconnects after the WAN is available again:

Code: Select all

Tue Apr 17 18:32:47 2018 daemon.notice openvpn(ctb_client)[1561]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
Tue Apr 17 18:32:47 2018 daemon.notice openvpn(ctb_client)[1561]: [VPN Server] Peer Connection Initiated with [AF_INET]151.236.8.117:1206
Tue Apr 17 18:32:48 2018 daemon.notice openvpn(ctb_client)[1561]: SENT CONTROL [VPN Server]: 'PUSH_REQUEST' (status=1)
Tue Apr 17 18:32:48 2018 daemon.notice openvpn(ctb_client)[1561]: PUSH: Received control message: 'PUSH_REPLY,comp-lzo,sndbuf 393216,rcvbuf 393216,route 10.102.0.1,topology net30,ping 9,ping-restart 30,route 10.1.0.0 255.255.0.0,route 10.100.0.0 255.255.0.0,route 10.101.0.0 255.255.0.0,route 10.102.0.0 255.255.0.0,ifconfig 10.102.0.114 10.102.0.113,peer-id 34,cipher AES-256-GCM'
Tue Apr 17 18:32:48 2018 daemon.notice openvpn(ctb_client)[1561]: OPTIONS IMPORT: timers and/or timeouts modified
Tue Apr 17 18:32:48 2018 daemon.notice openvpn(ctb_client)[1561]: OPTIONS IMPORT: compression parms modified
Tue Apr 17 18:32:48 2018 daemon.notice openvpn(ctb_client)[1561]: OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Tue Apr 17 18:32:48 2018 daemon.notice openvpn(ctb_client)[1561]: Socket Buffers: R=[425984->425984] S=[425984->425984]
Tue Apr 17 18:32:48 2018 daemon.notice openvpn(ctb_client)[1561]: OPTIONS IMPORT: --ifconfig/up options modified
Tue Apr 17 18:32:48 2018 daemon.notice openvpn(ctb_client)[1561]: OPTIONS IMPORT: route options modified
Tue Apr 17 18:32:48 2018 daemon.notice openvpn(ctb_client)[1561]: OPTIONS IMPORT: peer-id set
Tue Apr 17 18:32:48 2018 daemon.notice openvpn(ctb_client)[1561]: OPTIONS IMPORT: adjusting link_mtu to 1629
Tue Apr 17 18:32:48 2018 daemon.notice openvpn(ctb_client)[1561]: OPTIONS IMPORT: data channel crypto options modified
Tue Apr 17 18:32:48 2018 daemon.notice openvpn(ctb_client)[1561]: Data Channel: using negotiated cipher 'AES-256-GCM'
Tue Apr 17 18:32:48 2018 daemon.notice openvpn(ctb_client)[1561]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Apr 17 18:32:48 2018 daemon.notice openvpn(ctb_client)[1561]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Apr 17 18:32:48 2018 daemon.notice openvpn(ctb_client)[1561]: Preserving previous TUN/TAP instance: tun1
Tue Apr 17 18:32:48 2018 daemon.notice openvpn(ctb_client)[1561]: Initialization Sequence Completed

If I set "option persist_tun 0" (which is normally 1) AND the WAN disconnect is long enough to run into the OpenVPN timeout which removes then the tun interface, then the reconnect works fine, if the time between dis- and re-connect is too short, then the same problem happens there also.

This is a part of the log after the successful re-connection with "persist_tun 0" set:

Code: Select all

Tue Apr 17 19:17:11 2018 daemon.notice openvpn(ctb_client)[2919]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
Tue Apr 17 19:17:11 2018 daemon.notice openvpn(ctb_client)[2919]: [ VPN Server] Peer Connection Initiated with [AF_INET]151.236.8.117:1201
Tue Apr 17 19:17:11 2018 daemon.info odhcpd[1301]: Using a RA lifetime of 0 seconds on br-lan
Tue Apr 17 19:17:11 2018 daemon.notice odhcpd[1301]: Failed to send to ff02::1%br-lan (Address not available)
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: SENT CONTROL [ VPN Server]: 'PUSH_REQUEST' (status=1)
Tue Apr 17 19:17:12 2018 kern.info kernel: [ 3032.520084] br-lan: port 1(eth0) entered forwarding state
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: PUSH: Received control message: 'PUSH_REPLY,comp-lzo,sndbuf 393216,rcvbuf 393216,route 10.102.0.1,topology net30,ping 9,ping-restart 30,route 10.1.0.0 255.255.0.0,route 10.100.0.0 255.255.0.0,route 10.101.0.0 255.255.0.0,route 10.102.0.0 255.255.0.0,ifconfig 10.102.0.114 10.102.0.113,peer-id 34,cipher AES-256-GCM'
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: OPTIONS IMPORT: timers and/or timeouts modified
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: OPTIONS IMPORT: compression parms modified
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: Socket Buffers: R=[425984->425984] S=[425984->425984]
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: OPTIONS IMPORT: --ifconfig/up options modified
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: OPTIONS IMPORT: route options modified
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: OPTIONS IMPORT: peer-id set
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: OPTIONS IMPORT: adjusting link_mtu to 1629
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: OPTIONS IMPORT: data channel crypto options modified
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: Data Channel: using negotiated cipher 'AES-256-GCM'
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: TUN/TAP device tun1 opened
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: TUN/TAP TX queue length set to 100
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: /sbin/ifconfig tun1 10.102.0.114 pointopoint 10.102.0.113 mtu 1500
Tue Apr 17 19:17:12 2018 daemon.notice netifd: Interface 'vpn1' is enabled
Tue Apr 17 19:17:12 2018 daemon.notice netifd: Network device 'tun1' link is up
Tue Apr 17 19:17:12 2018 daemon.notice netifd: Interface 'vpn1' has link connectivity 
Tue Apr 17 19:17:12 2018 daemon.notice netifd: Interface 'vpn1' is setting up now
Tue Apr 17 19:17:12 2018 daemon.notice netifd: Interface 'vpn1' is now up
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: /sbin/route add -net 10.102.0.1 netmask 255.255.255.255 gw 10.102.0.113
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: /sbin/route add -net 10.1.0.0 netmask 255.255.0.0 gw 10.102.0.113
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: /sbin/route add -net 10.100.0.0 netmask 255.255.0.0 gw 10.102.0.113
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: /sbin/route add -net 10.101.0.0 netmask 255.255.0.0 gw 10.102.0.113
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: /sbin/route add -net 10.102.0.0 netmask 255.255.0.0 gw 10.102.0.113
Tue Apr 17 19:17:12 2018 daemon.notice openvpn(ctb_client)[2919]: Initialization Sequence Completed

This is my OpenVPN client config:

Code: Select all

client
float
nobind
persist-key
remote-random
auth-user-pass /etc/openvpn/user.pass
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
cipher AES-256-CBC
dev tun1
fragment 1344
key /etc/openvpn/client.key
mssfix 1
proto udp
remote vpn1.example.com 1194
remote vpn2.example.com 1194
remote-cert-tls server
reneg-sec 0
resolv-retry infinite
tls-auth /etc/openvpn/VPN_ta.key 1
verb 3

Any ideas what could cause this problem?

[TinCanTech]

Before I go on ..

Your client:

Code: Select all

mssfix 1

I am running an OpenVPN 2.4.4 on a LEDE Reboot (17.01.4, r3560-79f57e422d) in a Windows 10 Hyper-V container.

Sounds interesting .. maybe I'll have a go.

[michael.uray]

Your client:

Code: Select all

mssfix 1

Right, I did not notice this.
A colleague of mine did this config file there, but I think the reason is how the OpenVPN configuration is setup within the OpenWRT configuration:

The OpenVPN config there looks like this:

Code: Select all

config openvpn 'ctb_client'
        option client '1'
        option enabled '1'
        option dev 'tun1'
        option proto 'udp'
        option remote_random '1'
        list remote 'vpn1.example.com 1194'
        list remote 'vpn2.example.com 1194'
        option resolv_retry 'infinite'
        option nobind '1'
        option persist_key '1'
        option persist_tun '0'
        option float '1'
        option tls_auth '/etc/openvpn/VPN_ta.key 1'
        option ca '/etc/openvpn/ca.crt'
        option cert '/etc/openvpn/client.crt'
        option key '/etc/openvpn/client.key'
        option auth_user_pass '/etc/openvpn/user.pass'
        option remote_cert_tls 'server'
        option reneg_sec '0'
        option verb '3'
        option cipher 'AES-256-CBC'
        option fragment '1344'
        option mssfix '1'

If I remove the '1" after the mssfix, then the mssfix disappears from the OpenVPN config file which gets created by OpenWRT and I think for this reason he has set it to 1.
Not sure what effect it has with 1.
The best way would be probably to set it also 1344 like the fragment option. (I did so, but no change on the actual problem)

I am running an OpenVPN 2.4.4 on a LEDE Reboot (17.01.4, r3560-79f57e422d) in a Windows 10 Hyper-V container.

Sounds interesting .. maybe I'll have a go.

Pretty easy to setup, just convert the combined-squashfs.img (https://downloads.openwrt.org/releases/ ... uashfs.img) to a vhdx with the qemu-img how described there: https://cloudbase.it/qemu-img-windows/. After that you can use the output file as hard disk in the Hyper-V.
Just take care that you set the right permissions to the .vhdx file when you copy it into the Hyper-V folder. This took me some time to find out.

[michael.uray]

I have there some other topics related to this issue in the OpenWRT forum:

OpenVPN TUN interface loses IP address after WAN reconnect:
https://forum.openwrt.org/viewtopic.php?id=73853

Restart of all interfaces gets issued when LAN gets plugged in?
https://forum.openwrt.org/viewtopic.php?id=73873

OpenVPN client tun adapter loses its IP address on network restart:
https://forum.openwrt.org/viewtopic.php?id=73874

[TinCanTech]

Before I go on ..

Your client:

Code: Select all

mssfix 1

Right, I did not notice this.
A colleague of mine did this config file there, but I think the reason is how the OpenVPN configuration is setup within the OpenWRT configuration

You should check that with OpenWRT .. make sure of the syntax.

I am running an OpenVPN 2.4.4 on a LEDE Reboot (17.01.4, r3560-79f57e422d) in a Windows 10 Hyper-V container.

Like I said .. this looks interesting and I will follow up on your info.

However:

The machine has two Ethernet interfaces (LAN / WAN) which are connected to the LEDE system.

There is an OpenVPN client on the LEDE system which connects to an external server.
If I disconnect the WAN cable to the PC for a few seconds and reconnect it, then the tun interface loses its IP addresses during the OpenVPN reconnect and it never will get one assigned.

Pulling the cable out on a multi-homed system running Virtualisation .. try some other better test.

[michael.uray]

Pulling the cable out on a multi-homed system running Virtualisation .. try some other better test.

The following post describes, that the OpenVPN client tun adapter loses its IP address on a network restart.
https://forum.openwrt.org/viewtopic.php?id=73874
It happens on a Linksys WRT 1200 AC, directly on the hardware, without any virtualization.
Not sure if this is an OpenWRT related problem or a problem of its openvpn-openssl package, or of the OpenVPN itself.

It looks to me that a network restart happens when you plug in a cable to an interface on OpenWRT and this further causes then the problem:
https://forum.openwrt.org/viewtopic.php?id=73873

[michael.uray]

This shows the solution to this problem, it was cause by a tun1 device in /etc/config/network with "option proto none".
https://forum.lede-project.org/t/openvp ... rt/13825/2

[TinCanTech]

Great .. Thanks for letting us know your solution