Restart VPN client when certain error is logged

[Goobi]

Hi community,

I have a situation whereby I sometimes get the following error when starting openvpn client:

iptables v1.4.15: Couldn't load target `DNSVPN3':No such file or directory

Aside from this error the connection is established but clients lose connectivity because the DNS never loaded. Restarting the service manually resolves but it takes me a while to determine that this issue has occurred so looking to add some automation to recovering.

My question is can openvpn-event or some other method be used such that whenever this error is encountered when starting the vpn client that it could simply restart the service again?

Thanks in advance for any insights or tips.

 

[Martineau]

I have a situation whereby I sometimes get the following error when starting openvpn client:

iptables v1.4.15: Couldn't load target `DNSVPN3':No such file or directory

Aside from this error the connection is established but clients lose connectivity because the DNS never loaded. Restarting the service manually resolves but it takes me a while to determine that this issue has occurred so looking to add some automation to recovering.

My question is can openvpn-event or some other method be used such that whenever this error is encountered when starting the vpn client that it could simply restart the service again?

If a VPN Client stalls, then if you are using VPN_Failover.sh it should eventually restart the stalled VPN instance?

However, to be honest I suggest you diagnose why '/usr/sbin/updown.sh' is seemingly failing to honour the 'Accept DNS Configuration=EXCLUSIVE' GUI setting.

i.e. the script attempts to create the DNSVPN3 chain

/usr/sbin/iptables -t nat -N DNSVPN3

but silently fails, consequently when DNSVPN3 is later referenced, it doesn't exist? - hence the error message.

iptables -t nat -I PREROUTING -p udp -m udp --dport 53 -j DNSVPN3
iptables -t nat -I PREROUTING -p tcp -m tcp --dport 53 -j DNSVPN3

If a simple

service restart_vpnclient3

manages to fix it, it seems more by luck, i.e. how many times must the restart command be issued to guarantee that it will work?

 

[Goobi]

Thanks for the reply @Martineau!

When the instance is in this state the vpn_failover script says the connection is okay as curl succeeds.

As you mentioned, not sure why updown.sh is not honoring the exclusive setting for the accept dns configuration. While not pretty, I was thinking to workaround this by setting that value to relaxed and then setting a dnsfilter for my clients and pointing them to the vpn dns. Not sure this will work, but seems reasonable enough to try.

 

[Martineau]

Thanks for the reply @Martineau!

When the instance is in this state the vpn_failover script says the connection is okay as curl succeeds.

Doh , you're correct, curl in my VPN_Failover.sh script is not using the VPN Client 3 DNS, hence it doesn't detect that something is wrong with the DNS resolver.

Strangely, whilst the updown.sh script uses a very flaky method to extract the VPN Client instance, it only appears to possibly fail for the Server instance?

echo tun13 | sed "s/tun1//;s/tun2*/0/"
3

echo tun21 | sed "s/tun1//;s/tun2*/0/"
01            <<<- WTF ?

echo tun22 | sed "s/tun1//;s/tun2*/0/"
0

I think I will pass on adding my ugly DNS hack to VPN_Failover.sh ,as sadly I think your environment is an extreme edge-case.

P.S. Will be interesting to see if your ugly workaround fixes your issue.

 

[RMerlin]

Strangely, whilst the updown.sh script uses a very flaky method to extract the VPN Client instance, it only appears to possibly fail for the Server instance?

That regexp is indeed quite wacky, no idea why it was designed that way (that was inherited from Tomato back when I originally implemented OpenVPN in Asuswrt). This more straightforward regexp seems to work just fine:

sed "s/tun1//;s/tun2//;"

 

[Martineau]

That regexp is indeed quite wacky, no idea why it was designed that way (that was inherited from Tomato back when I originally implemented OpenVPN in Asuswrt). This more straightforward regexp seems to work just fine:

sed "s/tun1//;s/tun2//;"

Shouldn't the commit also take into account that variable $instance will now no longer be a digit 0-5 ?

Line 55:

    if [ $instance != 0 -a $(nvram get vpn_client$(echo $instance)_rgw) -ge 2 -a $(nvram get vpn_client$(echo $instance)_adns) == 3 ]
    then
        setdns=0
    else
        setdns=-1

 

[RMerlin]

It was a digit in my quick tests. I still need to do further testing however, I can't at the moment.

Sent from my ELE-L04 using Tapatalk

 

[Martineau]

It was a digit in my quick tests.

If the original intention was to differentiate between Client and Server, then rather than use 'sed' I would use

[ ${dev:0:4} = "tun1" ] && instance=${dev:4:1} || instance=0

 

[RMerlin]

If the original intention was to differentiate between Client and Server, then rather than use 'sed' I would use

[ ${dev:0:4} = "tun1" ] && instance=${dev:4:1} || instance=0

That would explain the reason for the weird regexp.

I'll review the whole block segment, at worst I will make it more straightforward like the code I wrote for contouring.sh.

Sent from my ELE-L04 using Tapatalk

 

[RMerlin]

After reviewing the OpenVPN code, updown.sh is not used by server instances, only client instances.

The regexp will also properly return a digit as long it's a valid interface:

admin@stargate88ax:/tmp/etc/openvpn/server1# echo "tun12" | sed "s/tun1//;s/tun2//;"
2
admin@stargate88ax:/tmp/etc/openvpn/server1# echo "tun15" | sed "s/tun1//;s/tun2//;"
5
admin@stargate88ax:/tmp/etc/openvpn/server1# echo "tun14" | sed "s/tun1//;s/tun2//;"
4
admin@stargate88ax:/tmp/etc/openvpn/server1# echo "tun13" | sed "s/tun1//;s/tun2//;"
3
admin@stargate88ax:/tmp/etc/openvpn/server1# echo "tun11" | sed "s/tun1//;s/tun2//;"
1

So, that commit look good to me. Not quite sure where the check against 0 came from, could have been just a bad C-ism when it was written.

 

[Martineau]

After reviewing the OpenVPN code, updown.sh is not used by server instances, only client instances.

The regexp will also properly return a digit as long it's a valid interface:

admin@stargate88ax:/tmp/etc/openvpn/server1# echo "tun12" | sed "s/tun1//;s/tun2//;"
2
admin@stargate88ax:/tmp/etc/openvpn/server1# echo "tun15" | sed "s/tun1//;s/tun2//;"
5
admin@stargate88ax:/tmp/etc/openvpn/server1# echo "tun14" | sed "s/tun1//;s/tun2//;"
4
admin@stargate88ax:/tmp/etc/openvpn/server1# echo "tun13" | sed "s/tun1//;s/tun2//;"
3
admin@stargate88ax:/tmp/etc/openvpn/server1# echo "tun11" | sed "s/tun1//;s/tun2//;"
1

So, that commit look good to me. Not quite sure where the check against 0 came from, could have been just a bad C-ism when it was written.

Ahh OK, whilst 'config.ovpn' always contains the 'updown.sh' directive (for OpenVPN Clients and Servers) the symlink in their respective configuration directory is indeed different.
e.g.

ls -lah /etc/openvpn/server1

drwx------    2 admin    root         240 May  5 13:06 .
drwx------    7 admin    root         200 May  7 08:20 ..
-rw-------    1 admin    root        1.2K May  5 13:06 ca.crt
-rw-------    1 admin    root         916 May  5 13:06 ca.key
-rw-rw-rw-    1 admin    root        6.0K May  5 13:06 client.ovpn
-rw-------    1 admin    root        1.0K May  5 13:06 config.ovpn
-rw-------    1 admin    root         432 May  5 13:06 dh.pem
-rw-------    1 admin    root        1.3K May  5 13:06 server.crt
-rw-------    1 admin    root         932 May  5 13:06 server.key
-rw-------    1 admin    root         472 May  7 08:23 status
lrwxrwxrwx    1 admin    root          27 May  5 13:06 updown.sh -> /jffs/scripts/openvpn-event
-rwx------    1 admin    root          78 May  5 13:06 vpns-watchdog1.sh

ls -lah /etc/openvpn/client1

drwx------    2 admin    root         200 May  7 08:20 .
drwx------    7 admin    root         200 May  7 08:20 ..
-rw-------    1 admin    root        2.2K May  7 08:20 ca.crt
-rw-------    1 admin    root        2.2K May  7 08:20 client.crt
-rw-------    1 admin    root        1.6K May  7 08:20 client.key
-rw-------    1 admin    root        1012 May  7 08:20 config.ovpn
-rw-------    1 admin    root         262 May  7 08:23 status
-rw-------    1 admin    root          32 May  7 08:20 up
lrwxrwxrwx    1 admin    root          19 May  7 08:20 updown.sh -> /usr/sbin/updown.sh
lrwxrwxrwx    1 admin    root          23 May  7 08:20 vpnrouting.sh -> /usr/sbin/vpnrouting.sh

So actually there is no need for the commit anyway, but just in case.....

 

[RMerlin]

Ahh OK, whilst 'config.ovpn' always contains the 'updown.sh' directive (for OpenVPN Clients and Servers) the symlink in their respective configuration directory is indeed different.

There might be an actual bug there, but a different one. My server config.ovpn had no updown.sh reference here, meaning openvpn-event would never get fired for the server.

 

[Xentrk]

Shouldn't the commit also take into account that variable $instance will now no longer be a digit 0-5 ?

Line 55:

    if [ $instance != 0 -a $(nvram get vpn_client$(echo $instance)_rgw) -ge 2 -a $(nvram get vpn_client$(echo $instance)_adns) == 3 ]
    then
        setdns=0
    else
        setdns=-1

When I was customizing updown.sh and vpnrouting.sh, I was getting many errors when running the code thru https://www.shellcheck.net/ From @RMerlin post, looks like it may be old Tomato code. May be time for an update! For example:

For reference, current line:

if [ $instance != 0 -a $(nvram get vpn_client$(echo $instance)_rgw) -ge 2 -a $(nvram get vpn_client$(echo $instance)_adns) == 3 ]

Here is the POSIX compliant version for Line 55 according to https://www.shellcheck.net/:

if [ "$instance" != 0 ] && [ "$(nvram get vpn_client"${instance}"_rgw)" -ge 2 ] && [ "$(nvram get vpn_client"${instance}"_adns)" -eq 3 ];

Here are a few other complaints:

• SC2086: Double quote to prevent globbing and word splitting.
• SC2046: Quote this to prevent word splitting.
• SC2116: Useless echo? Instead of 'cmd $(echo foo)', just use 'cmd foo'.

Also does not like the -a or =-o operators. Those appear to be from the old code.

Prefer [ p ] && [ q ] as [ p -a q ] is not well defined.

I was running with the POSIX code briefly. But backed out the changes as I have other custom code in updown.sh and vpnrouting.sh I was developing at the time. I wanted to keep my changes minimal until development settled down so I backed out the POSIX updates. Looking things over again, the effort to make POSIX compliant looks like an effort worth taking on and not that time consuming. I can fork, make the changes, then submit a pull request.

 

[RMerlin]

I'll take care of the most obvious coding style issues in the 384.12 rework of that script.