OpenWrt Forum Archive

Topic: OpenVPN problem during system startup

The content of this topic has been archived on 6 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hello!

I've setup openvpn server and almost everything works as expected. Now here is the issue. When the openvpn daemon is started manually, then the ip prefixes are added to the kernel routing table and the ip address of the tun device is configured. But if the daemon is added to run during system startup, whether via "/etc/init.d/openvpn enable" or "/etc/init.d/openvpn start" inside "/etc/rc.local", then it starts as expected and the tun device is up but without ip configuration and there are no routes added to the kernel. There are no errors. Neither the openvpn log nor the logread tells anything useful. The daemon can successfully accept client connections and etc. Whether the openvpn is run manually or during system startup, the only differences are the missing ip configuration of the tun device and the missing ip routes from the kernel routing table.

The OpenWRT release is 14.07, rev. r42625.
The OpenVPN-polarssl ver. is 2.3.4-1

OpenVPN uses external custom config as allowed by the first section inside "/etc/config/openvpn".

"/etc/rc.d/" sequence number of the openvpn startup script is 90. There are only three scripts after it - 'done', 'led', 'ntpd', in that order.

It is a stock firmware, no additional packages but OpenVPN.

Any help, clues or whatever, would be appreciated.

Thanks in advance!

5 seconds sleep added before the execution of the openvpn startup script made it behave as expected, i.e. tun ip configuration and kernel ip routes are present. I suspect the culprit is that the openvpn startup sequence is too early in the chain and some other daemon, responsible for the network configuration isn't finished yet.

Interesting, I have multiple openvpn instances (servers and clients) starting up at 90 in rc.d, and never experienced anything like that. Might be an issue with your particular OpenWrt or OpenVPN config.

"/etc/init.d/network restart" clears everything that is not part of the uci network configuration while "reload" does not. Perhaps something along the startup line triggers network "restart" and removes the ip settings set by the OpenVPN. The time delay, which I introduced, postpone the launch of the OpenVPN and that gives just enough time to skip the triggered "network restart" event or whatever there is playing with the network settings.

I do not believe that OpenVPN configuration has anything to do with it because the OpenVPN would not work or would indicate that something is amiss in the log file. Actually, OpenVPN is completely unaware that something else is playing with the network settings.

Bump.

Same problem here. Anyone got a real fix?
Thanks!

ditto on CC 15.05

Funny, I have just run the latest r49395 to see if the problem I reported here https://dev.openwrt.org/ticket/20729#comment:7 is fixed, only to find out that even if I completely disable vpn interface in /etc/config/network it does not help. Openvpn starts first (according to the system log) far earlier than network and while all interface setup succeed at the end after the system is fully up, tun0 interface is DOWN with no address etc.

BTW: I am running openwrt on TP-LINK TL-WR1043ND-v2

Your miscofiguration in the this point: You created the "interface" for the ifname tun0 (tun1, ...) and the script /etc/init.d/network re-initialise the interface. To solve problem simple remove the definitions of the interfaces with the "iface tun*"

I have the same issue; 'tun0' is mentioned inside interface vpn0 as an ifname....
If I remove the vpn0, then basic tun is working, but I lose the ability to setup firewall & routing, so clients can't route out of the router.

simonh wrote:

I have the same issue; 'tun0' is mentioned inside interface vpn0 as an ifname....
If I remove the vpn0, then basic tun is working, but I lose the ability to setup firewall & routing, so clients can't route out of the router.

This is big problem, because without creating "vpn zone" it is impossible to forward vpn traffic to lan zone.
Or should i use "firewall.user" to create iptable rules manually? who solved this problem?

It is possible to specify interface device directly in the firewall zone definition:

config zone
    option name          vpn
    list   device        tun0
...

(Last edited by rovall on 6 Aug 2017, 00:27)

thx.
This helped to solve the problem without restarting openvpn during boot.

config/network

config interface 'vpn0'
        #comment to prevent reinitialize tun0 interface
        #option ifname 'tun0'
        option proto 'none'
        option auto '1'

config/firewall

config zone
...
list   device        tun0
...

The discussion might have continued from here.