OpenVPN Periodic Disconnection


Hi @caste381 I had over a day without having to manually reconnect, but the connection still dropped a few times with the difference being that it connected again without me having to manually do it.

Agree @skycatcher it’s a big improvement with Glitch’s changes. Are you NordVPN or Getflix? I’ve used both services but I’m currently using Nord.

An issue I’m having, and I’m not sure if it’s just my office, but when I connect to a server that is not too near e.g France when I’m in UK, it disconnects after just a few minutes and reconnects again then drops connection again.

Not sure which line is causing the issue. I’m going to play around to see.


Thanks all.

I will try.


Zimo - I’m with Getflix but are experiencing the same as yourself…the further away the vpn server the the more volatile the connection. Using a UK server gives the longest connection but like you it is doing the reconnection for you now where before it was just failing!




Does anyone know where I can access the ovpn log? (I know the logread command but think that may just be generally for the router rather than specifically for VPN).


That seems to have worked for me too. My NordVPN connections now re-establish automatically.



Hi guys, could someone please repost the “definitive” settings that people are using? It’s hard to follow the thread. I’m also using NordVPN.

In the meantime, I came up with a restart script that has kept me up for days now, based on scraps of bash recovered from startup scripts. I know other people have posted scripts before but this might help someone. I have tested it a fair bit and have verified it a) keeps the connection up (restarts it) and b) at no point allows non-VPN traffic through IF that’s how you’ve set things up.

I run the following every 5 mins as a cronjob:


# Should openvpn already be in operation? If not, nothing to do, exit.
enabled=$(uci get glconfig.openvpn.enable)
vpn_client=$(uci get network.VPN_client)    # removed when startvpn stopped explicitly

if [ "$enabled" != "1" ] || [ "$vpn_client" != "interface" ]; then
exit 0

# First hop should be to the internal VPN gateway ( if VPN up.
# If we're going through VPN then all is well, do nothing.
first_hop=$(traceroute 2>&1 | head -2 | tail -1 | awk '{print $2}')

if [ "$first_hop" == "" ]; then
logger -t VPN_restart VPN is fine.
exit 0

killall openvpn 2>/dev/null
ovpn=$(uci get glconfig.openvpn.ovpn)
/usr/sbin/openvpn "$ovpn" &
(sleep 1; /etc/init.d/network reload) &

logger -t VPN_restart VPN was down and had to be restarted.

I’m happy to give more detail, but I get the impression that a proper fix has been found for the ovpn file.


Hello Merlot,

here is my config for a TCP VPN:




dev tun

proto tcp

remote X.X.X.X 443

resolv-retry infinite



tun-mtu 1500

tun-mtu-extra 32

mssfix 1450



keepalive 10 60

auth-retry interact


reneg-sec 0

remote-cert-tls server

pull-filter ignore “auth-token”

auth-user-pass /etc/openvpn/auth/XXX.txt


verb 3



cipher AES-256-CBC





key-direction 1



-----BEGIN OpenVPN Static key V1-----

-----END OpenVPN Static key V1-----




With this configuration the connection might drop every so often but in the last 48 hours it has always reconnected automatically.

Thanks for sharing the script. I might actually use it as a base for an idea I had, if I can find the time:



Reporting back - seems the changes I suggested improve things a lot. I still get “outages” (yellow triangle in WIndows) but it now (eventually) reconnects itself (however, not after 60 seconds which “keepalive 10 60” seems to suggest it should).

@ merlot: I tried my own recconect script without much success but your efforts gave me renewed impetus (script further down).

I tried to dissect your script. I have very limited ability, so please bear with me if I am talking nonsense. I struggled with the first part because of too many negatives ("!"and “||”).How about just doing this and letting the script run through?:

if [ "$enabled" = "1" ] && [ "$vpn_client" = "interface" ]; then

Regarding the traceroute part: Am I right thinking the “head” and “tail” part cut the first and last part of the IP address to two digits and one digit repsectively?
Also, I don’t think this would work with other providers, as the NAT address (?) seems particular to Nord.
The last three lines seem to do the same as:

/etc/init.d/startvpn start

Finally, my script, which seems to work and can be run every two minutes (or five, if you prefer). I would welcome your comments:

if ! ping -I tun0 -c5 -w5; then
killall openvpn # 2>/dev/null (took this out because I don't understand it)
ovpn=$(uci get glconfig.openvpn.ovpn)
/usr/sbin/openvpn "$ovpn" &
(sleep 1; /etc/init.d/network reload)



PS. I give up trying to format my posts as the forum software has a mind of it’s own and is hopeless! Twenty attempts and I still can’t get a new paragraph (<p>) or two line breaks (<br><br>)!!!



Thanks! I will try those.



The purpose of

if [ “$enabled” = “1” ] && [ “$vpn_client” = “interface” ]; then

is to basically detect if startvpn was supposed to be run and in fact was run. If not exit. I don’t want to try to fix a broken service/VPN connection that was actually never started. It’s a defensive approach. I’m getting these “uci” settings from the startup scripts.

The purpose of

first_hop=$(traceroute 2>&1 | head -2 | tail -1 | awk '{print $2}')

is to capture the first IP address on the route out to “”, which will be on the second line of the output. Unless I get the expected IP, something is wrong. (head takes top two lines of output, tail takes the bottom line of those two. awk plucks out the IP.)

Your point about emails belonging to NordVPN sounds like a good point. Must have lulled myself into the notion that it was some kind of internal address. If this is the case, you would need to change it and this is a flaw in the script.

One of the reasons I used traceroute instead of your ping line was because I wanted to avoid a reference to tun0 (in case it came up tun1 or something) but this is not nearly as bad as hardcoding an external IP! So yours might be better.

Of course (potential change of IP aside) mine at least has the benefit of working well. No downtime now since the change. As in, my connection can be seen in the logs to drop, but it’s always restored correctly.

One weird thing though: even though the script runs in 1/2 seconds from a command line. It can take 2.5mins through cron, which is very odd. (The traceroute is running all the time.) I also need to adopt the correct VPN settings so that daily restarts are not needed either.


Thanks for the further explanations.

>>>> It can take 2.5mins through cron, which is very odd

I think this is the same problem as the Keepalive 10 60 delay. My theory is that the remote server goes down and takes this time to come back up - with my new ovpn settings, it once took over 5 minutes to reconnect.


Well after eventually getting something that was workable with thanks to you guys my router died last night! So that’s away back to Amazon! Trying to decide what to do next wrt my VPN solution.


@merlot: can you tell me how you set the cron job, as I can’t get it to work on my AR300M.

I checked that cron is enabled and started and tried several variantions of “*/5 /” to try and schedule the script.
I checked and ran the script from WinSCP/Terminal and it works fine.

As an aside, what does the “-t” do on the logger -t line (I found the command worked without it)?



@Glitch Firstly, I’m using the MT300N model. To set up a cronjob, I did the following:

crontab -e

and entered:

*/5 * * * * /root/VPN_restart

which is the name and location of my script.

I also ran a few other commands, which may or may not be necessary, to ensure that cron was running:

/etc/init.d/cron start

/etc/init.d/cron enable

You can actually interact with cron through the web panel as well: Advanced settings > System > Scheduled tasks.

As for the “-t” option, it just adds a “tag” to the log so that logs reference the tag as opposed to user.root or whatever the default is. (There is a man page out there but I can’t find it right now!)




Thanks for your help - seems I wasn’t doing anything wrong…but still can’t get it to work - I think there is a permission problem with cron in the Arm300 firmware (will open a new thread and ask there).

Edit: fixed the problem - had the wrong path - this did it:

*/1 * * * * /path/to/script/


I look forward to testing the crontab approach, just so I am doing it properly, do I keep the .ovpn file the same as above or remove the reconnect section which will now be handled by the crontab script?

Awesome work :slight_smile:


If using a script you could leave the OVPN as is (but I changed mine as per my post above) then use the script (mine or Merlot’s) to check connection.


Very good, script is in use! thx!!


Sorry, I have noob questions:

  1. Where can i find ovpn log file?
  2. Where can i find ovpn config file?
  3. If the PID is still listed as numbers in process on luci, is it actually still running?
  4. So what setting i have to change in the config file? Is it only auth-retry interact -> auth-retry nointeract? Or is it something else?



  1. install rsyslog (opkg update; opkg install rsyslog) . they will be in /var/log/messages
  2. /etc/openvpn
  3. yes

if you are on firmware 2.7x there is a bug in the scripts if you have the switch configured to turn on and off vpn. it causes two openvpn processes to start that conflict with eachother. if you have it enabled, disable the switch setting and reboot the router to see if that fixes your issue.


If I change the ovpn config (auth-retry interact -> auth-retry nointeract?), do I still need to disable the switch?