OpenVPN client tun adapter loses its IP address on network restart


#1

Hi guys,

the OpenVPN tun adapter loses its IP address when a
/etc/init.d/network restart
gets issued.

Before the network restart:

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.182  P-t-P:10.102.0.181  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:52 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:8722 (8.5 KiB)  TX bytes:6120 (5.9 KiB)

After the network restart:

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:52 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:8722 (8.5 KiB)  TX bytes:6120 (5.9 KiB)

The OpenVPN connection to the server is then still established, but not usable since there is no IP address on the tun interface.

It does not come back on its own and there is any action like "/etc/init.d/openvpn restart" required to get the interface up and running again.

Tested with a LEDE Reboot (17.01.4, r3560-79f57e422d) on a LinksysWRT 1200 AC.

Any ideas what could cause this issue and how to fix it?


Openvpn basic missing network/firewall passages
[SOLVED] Unable to connect to OpenVPN server on wrt1900ac running 18.06.2
#2

This caused by referencing the tun1 device in /etc/config/network with option proto none - it will cause netifd to clear all settings on this device when network is restarted.

Best remove the dummy interface declaration to prevent netifd from interfering with openvpn. You can use option device tun1 in /etc/config/firewall instead if you want to assign it to a zone.


OpenVPN issue/question
#3

Thank you very much jow, this helped me a lot!

I just removed the tun interfaced from the "/etc/config/network" file and changed my firewall settings in /etc/config/firewall how you recommended.

config zone
        option forward 'REJECT'
        option input 'ACCEPT'
        option name 'VPN'
#       option network 'vpn0 vpn1'
        option device 'tun0 tun1'
        option output 'ACCEPT'


#4

Another way to prevent this would be setting a static IP for the VPN server in the server config, as well as in the network config

  • /etc/config/network
         # OpenVPN #
     #---------------------------------------------------
     config interface 'vpn'
         option  ifname          'tun0'
         option  proto           'static'
         option  ipaddr          '10.1.1.1'
         option  netmask         '255.255.255.248'
         option  broadcast       '10.1.1.7'
         option  dns             '192.168.1.1 208.67.222.222 208.67.220.220'
         option  delegate        '0'
    

  • /etc/config/openvpn
         # Protocol #
     #---------------------------------------------------
         option  dev             'tun'
         option  dev             'tun0'
         option  topology        'subnet'
    
    
         # Routes #
     #---------------------------------------------------
         option  server          '10.1.1.0 255.255.255.248'
         option  ifconfig        '10.1.1.1 255.255.255.248'
    

#5

Is this issue actually still present?

I just have seen in the current OpenVPN user guide that it is described there to assign the VPN-interface to a VPN-network.
If yes, then this could lead other users into the same troubles.


#6

I just tested it, the problem is still present.

What would an apropriate way to get rid of this issue, except of setting up a static IP address?
Some kind of hotplug script which also restarts the according VPN server with the network?
Or is there a way to prevent netifd to clear all settings on this device?


#7

I've updated the guide to use firewall zone option device.

Proper solution requires one of those:

  • Do not reset L3-data for protocol none on service network restart.
  • Implement network interface option persistent or unmanaged.
  • Implement network protocol type openvpn or unmanaged.

Workarounds: