OpenVPN TCP/UDP tunneled doesn't work until process restart

Installing and Using OpenWrt Network and Wireless Configuration
1

Hi all
I am experiencing a quite annoying problem with OpenVPN (both openssl and mbetls version) running in server, TCP, tunneled mode.
It does not work until I restart the process after router startup. To be more precise, the clients can connect perfectly to the server, but it seems that the data format cannot be understood between client and servers. I get the same problem (invalid key format, etc...) like when you run comp-lzo server with client configured without comp-lzo.
It is enough to just restart the openvpn process to solve the problem, until the next router restart.

This is my server configuration:

ca /etc/openvpn/ca.crt cert /etc/openvpn/my-server.crt comp-lzo adaptive dev tun dh /etc/openvpn/dh2048.pem keepalive 10 120 key /etc/openvpn/my-server.key log /tmp/openvpn.log port 443 proto tcp push "redirect-gateway def1" push "dhcp-option DNS 192.168.182.1" server 10.8.0.0 255.255.255.0 verb 3

and this is one of my client configuration

dev tun proto tcp http-proxy 165.225.86.32 80 log /var/log/menion_client.log verb 3 mssfix client remote-cert-tls server remote x.x.x.x 443 comp-lzo redirect-gateway def1 script-security 2 up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-conf ca /etc/openvpn/ca.crt cert /etc/openvpn/my-server.crt key /etc/openvpn/client.crt

2

time of the devices ? may be you should restart because at first the datetime is bad and could not verify encryption.

Is there is something on logs?

3

According to the startup priority the date and time should not be an issue. Also, there should be an RTC keeping the date across the restart. And the problem affect 3 different router (LinkSys EA4500, TPLink WDR3600 and Archer C7).
I am quite surprised that no one else have the same problem, the configuration I have is a very standard server configuration, so I really cannot understand what is going wrong here...
Meanwhile I have added a sleep 5 and openvpn restart in the custom init script and I have a working workaround at least...

4

Also, there should be an RTC keeping the date across the restart.

actually, most access points do not have a battery backed RTC, so they do not
keep track of time when powered off.

5

Same issue here, I'm using WNDR3800 and a standard OpenVPN config from OpenWRT official tutorials.

I have to add a boot() {} under init script and delay the OpenVPN startup to work around.

6

I have experienced the same issue. I added a 30 second sleep in the /etc/init.d/openvpn file (at the beginning of the start_service function) and I changed the boot priority to 99 (from 90). Works every time with these changes (maybe less time would be okay, but I figured this works).

I'm using a Ubiquiti RouterStation Pro for the hardware.

FWIW, at my Father's house, I have the same hardware (UBNT RS-Pro) and most of the same software installed, but with OpenWRT CC installed -- it does not have any issues requiring a startup delay. I think I first noticed this issue (and used the startup delay as a workaround) when I updated my local device from CC to LEDE some time back (I'll actually be updating my dad's VPN config to LEDE next week). I'm not sure what is different (at the lower levels) in terms of the boot-time activities and service startup process that would necessitate the delay for OpenVPN to work.

7

The problem is the date&time.
In LEDE something changed in the startup sequence, so Openvpn is started before the time is get via NTP, so if your board does not have a RTC, Openvpn cannot start due to certificate Date issue

8

hello psherman, how did you exactly added the boot priority? I added th sleep 30s in the start_service as you did but after the router restarts the openvpn service does not work.
I am a bit of a newbie in this subject, could you please clarify a bit more?

Also it would be interesting to see how exactly EvianZhow inserted the boot() in the init script.

9

@erountri15 -

I made the following changes to my openvpn init script (showing changes only, otherwise it is the default, the start number and then adding the sleep line right after the start_service() function).

/etc/init.d/openvpn 
START=99

start_service() {
	sleep 30

Don't forget to enable the openvpn init, as well.
/etc/init.d/openvpn enable

Then try restarting your router and see if it works.

All I am really doing is delaying the openvpn initialization a bit to make sure that the system has the correct (current) time which it will get via NTP once all the networking is enabled and it is connecting to the internet. If 30 seconds doesn't work, try something longer.

10

Hey Peter, I just tried what you said and it worked. I understand it just delays the openvpn start, but I believe it is a fair workaround.

For me the main takeaway is enabling the /etc/init.d/openvpn script. I had no clue it was disabled by default.

Thank you!

11

@erountri15 - glad it worked.

A more elegant solution might be to poke at the NTP process *or something similar) looking for a successful time acquisition, and then allowing the openvpn process to start. But this simple 30 second delay was a good 'hammer' and has worked flawlessly for me to date.

I think I have seen the OpenVPN init enabled when I don't want it to autostart, and disabled when I do... but I may be just making that up from a number of various experiences in the setup of both the server and client sides (on routers with LEDE/OpenWRT). When in doubt, I check that first to see what it is currently configured to do.

12

I also noticed problems on the OpenVPN server after a reboot some time ago.
It did not assign an IP address to the tun interface if I remember correctly and the problem described above looks like the same to me.

I just added in the file "/etc/rc.local" a delay and a restart:

sleep 20
/etc/init.d/openvpn restart
13

You can place a script in /etc/hotplug.d/ntp/ to restart openvpn once time has been synced. This way you do not need to add arbitrary delays blocking the boot sequence.

# cat /etc/hotplug.d/ntp/99-restart-openvpn
#!/bin/sh

if [ "$ACTION" = stratum ]; then
    /etc/init.d/openvpn restart
fi
14

This should definitely go in a proper PR for openvpn package in openwrt

15

I have encountered the same problem. Client connects to OpenVPN server, receives its address, but can't ping VPN server address. I have noticed that there is no IP address on tun0 interface when problem occurs. My solution was to check if wan address is already initialized.

Open /etc/init.d/oepnvpn and add the following lines at the beginning of start_service()

    while :
    do
      ip addr show eth0 | grep 'inet '
      if [ $? -ne 0 ]; then
        sleep 1
      else
        break
      fi
    done

Remember to replace eth0 with you wan device.

1 Like