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.
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.
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 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?
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.