OpenVPN client tun adapter loses its IP address on network restart

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:  P-t-P:  Mask:
          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
          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?

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.


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'

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          ''
         option  netmask         ''
         option  broadcast       ''
         option  dns             ''
         option  delegate        '0'

  • /etc/config/openvpn
         # Protocol #
         option  dev             'tun'
         option  dev             'tun0'
         option  topology        'subnet'
         # Routes #
         option  server          ''
         option  ifconfig        ''
1 Like

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.

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?

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.


1 Like

I think the 'persistent/unmanaged' solution proposed by @vgaetera could lead to improper system behaviour.

Implementing of 'unmanaged' protocol/interface type would have destructive consequences like a broken HOTPLUG functionality for network interfaces representing the OpenVPN tun/tap devices.

Setting protocol/interface type to 'unmanaged' will block HOTPLUG trigger functionality for such interfaces.
Expected behavior will be that no more HOTPLUG events will be generated for such interfaces because 'unmanaged' nature of protocol/interface.

The proposal above is unacceptable because of the fact that many users including me are relying on HOTPLUG scripts while setting up and controlling local OpenVPN environment (routes, ip rules and many other things).

IMHO the more suitable solution would be to implement some kind of general network protocol type 'dynamic' without associating it with any real underlying network protocol.

The behavior for such protocol type during the 'network reset' routine should be in sending some kind of RESET signal (SOFT RESET or HARD RESET) to the associated device or service associated with device.
In response to RESET signal the device or service associated with the device should perform soft or hard reset leading to re-assigning network parameters to the corresponding logical interface.

I have no idea what is the problem to implement the similar to described above behavior right now for the 'none' proto type without adding some other proto type or interface type?

Why just right now in response to tun/tap device reset during 'network reset' OpenVPN or system scripts are not doing tunnel RESET and not performing ifconfig of the associated logical interface?

I'm a newbie to OpenWRT but maybe there is somebody from the dev team here who could explain such improper system behavior in response to device reset event?

No worries, that way should work fine since you can still use the up/down scripts.

Use of up/down scripts is a quite insecure and non-enterprise method.

Using of 'script-security' may cause security issues.
Moreover, in some cases script execution permissions appears to be insufficient to perform all the required configuration tasks.
This forces us to create a separate user account for OpenVPN and grant special privileges for that account on a system level.
For security reasons it's preferable for OpenVPN daemon not to use up/down scripts and thus run under nouser/nogroup all the time after connection is established.

In addition, up/down method requires that all instances (client profiles) to be reconfigured accordingly.
This needs additional configuration steps (in most cases performed manually).

The only proper method is to use ONE hotplug script for ALL ovpn interfaces at once.

Unfortunately the issue described in this 3-year old thread is preventing hotplug-based method from working consistently.

PS: I'm asking myself is there a chance for this issue to be resolved ever?
IMHO this project looks abandoned.

There are some changes in the next release linking OpenVPN scripts with hotplug.
Unfortunately, the discussed race condition is unlikely to be fixed in the foreseeable future.
Anyway, those who have ever tried WireGuard are unlikely to return to OpenVPN.

It's NOT working!
See my post for details:

UPDATE: Filled a bug to the 'packages' bugtracker:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.