How to auto-restart remote clients (an Asus RT-AC68U) OpenVPN client

[sipankh]

How to auto-restart remote clients (an Asus RT-AC68U) OpenVPN client.

The setup is:
- On one end (THE CLIENT), I have Asus RT-AC68U running AsusWrt-Melrin code 386.11_0, and on the other side (THE host of the OpenVPN server) Asus RT-AX86U running AsusWrt-Merlin code 3004.388.4. Works like a charm. There are no issues with the performance, however....

The problem:
- On Asus RT-AX86U I go about nightly reboots at 3 am. The reboot is successful, and things run on it as configured...however
- Every time the reboot is completed the client DOES NOT auto connect after the reboot. Every single time I have to remote my self into the RT-AC68U (not directly; I have other devices on that side where I connect and use them to manage the RT-AC68U side) and have to enable that client side to connect. It connects without any problem and the session is live and in use till the next days 3am reboot on the OpenVPN server-side / RT-AX86U

Question(s):
- How do I ensure the client side will reconnect without manual intervention?
- Is there a script out there for this, i.e. did anyone potentially experience the same issue and coded a scripted solution? (asking 'cause I am not a scripter)
- Any info is welcomed since so far I have failed to find any info regarding the same problem and how to address it.

THank you in advance.

 

[ColinTaylor]

Obvious question: What do you have set for Connection Retry attempts in the client config?

 

[sipankh]

Obvious question: What do you have set for Connection Retry attempts in the client config?

It used to be 3 now is set to 0 i.e. infinite.

 

[ColinTaylor]

It used to be 3 now is set to 0 i.e. infinite.

Let us know if that fixes it.

 

[sipankh]

This is the screenshot of the client config page. Covered in blue is info that I have to cover due to security and irrelevant for the problem at hand.

It used to be 3 now is set to 0 i.e. infinite.

 

[sipankh]

Let us know if that fixes it.

That didn't fix it hence why I decided to post the question. The change from 3 to 0 was done a few days back and no changes. Same issue. Every single time I have to remote and start the client manually.

 

[ColinTaylor]

Try turning off the VPN kill switch.

 

[sipankh]

Try turning off the VPN kill switch.

That could be an issue if you are suggesting that I disable "Killswitch - Block routed clients if the tunnel goes down" option at the client side. Why? Well, if the VPN tunnel goes down, as it will at 3 am reboot, the devices I exclusively must have on the VPN tunnel on the client end will start attempting the routing of their data pockets to the non-tunnel routes and that is a BIG issue on my end.

What do I accomplish by enabling devices to route where they are not supposed to be routed?

 

[ColinTaylor]

It's just a test you could try now to try and diagnose the cause.

 

[sipankh]

Just tested what you proposed. Did it two ways to be sure I got viable results.

1. I did it by just going about soft reboot by issuing a reboot command from the command line (pretty much the same as using the "reboot" button you would likely agree

and

2. By cutting off the power for about 2-3 minutes from the Asus RT-AX86U (THE OpenVPN serverside)

In both instances, the remote client was connected after the reboot. I will leave it as is since it appears this could be that "magic bullet" I was searching for.

The question would be now, why? I wonder if would this be a good question for the AsusWRT-Merlin developers.

In any event, thank you, Colin, I highly appreciate it.
Regards, Sasha (the name behind the user name)

 

[DocUmibozu]

Try to change from TCP to UDP

 

[sipankh]

Just tested what you proposed. Did it two ways to be sure I got viable results.

1. I did it by just going about soft reboot by issuing a reboot command from the command line (pretty much the same as using the "reboot" button you would likely agree

and

2. By cutting off the power for about 2-3 minutes from the Asus RT-AX86U (THE OpenVPN serverside)

In both instances, the remote client was connected after the reboot. I will leave it as is since it appears this could be that "magic bullet" I was searching for.

The question would be now, why? I wonder if would this be a good question for the AsusWRT-Merlin developers.

In any event, thank you, Colin, I highly appreciate it.
Regards, Sasha (the name behind the user name)

It didn't work and back to square one.

 

[ColinTaylor]

It didn't work and back to square one.

Look in the remote client's System Log to determine why it didn't reconnect.

 

[sipankh]

Try to change from TCP to UDP

Made a change (nothing to loose trying) and will wait for tonight's auto-reboot. Testing and forcing the reboot gives positive results and then when I leave it to auto reboots negative ie never re-connects.

 

[sipankh]

Look in the remote client's System Log to determine why it didn't reconnect.

This is from the log at the time of the reboots (only IP has been removed for security):

Aug 31 03:00:09 ovpn-client1[1302]: Connection reset, restarting [0]
Aug 31 03:00:09 ovpn-client1[1302]: SIGUSR1[soft,connection-reset] received, process restarting
Aug 31 03:00:09 ovpn-client1[1302]: Restart pause, 1 second(s)
Aug 31 03:00:10 ovpn-client1[1302]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Aug 31 03:00:10 ovpn-client1[1302]: TCP/UDP: Preserving recently used remote address: [AF_INET]X.X.X.X:443
Aug 31 03:00:10 ovpn-client1[1302]: Socket Buffers: R=[87380->87380] S=[16384->16384]
Aug 31 03:00:10 ovpn-client1[1302]: Attempting to establish TCP connection with [AF_INET]X.X.X.X:443
Aug 31 03:00:10 ovpn-client1[1302]: TCP: connect to [AF_INET]X.X.X.X:443 failed: Connection refused
Aug 31 03:00:10 ovpn-client1[1302]: SIGUSR1[connection failed(soft),connection-failed] received, process restarting
Aug 31 03:00:10 ovpn-client1[1302]: Restart pause, 1 second(s)

Not sure I understand why would connection be refused.

 

[ColinTaylor]

The connection is refused because the server is down, so that's expected. What we need to know is how long it keeps retying the connection and when/why it stops trying.

 

[sipankh]

The connection is refused because the server is down, so that's expected. What we need to know is how long it keeps retying the connection and when/why it stops trying.

I decided to change the reboot times and see if that fix the issue. What do I mean by that? Well, both ends have been scheduled to reboot at the time time. Now I am changing one to reboot at 3 am and the other at 4am (different timing) to allow both ends to go through the cycle without OpenVPN client awaiting server to be ready, which I think might be the issue here. ...am not sure but that is to me logical to try.

What I see is this second after the failure to establish conenction ie the refusal (removed IP's and host names with Device X - X 6:
Aug 31 03:00:11 ovpn-client1[1302]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Aug 31 03:00:12 ovpn-client1[1302]: TCP/UDP: Preserving recently used remote address: [AF_INET]X.X.X.X:443
Aug 31 03:00:12 ovpn-client1[1302]: Socket Buffers: R=[87380->87380] S=[16384->16384]
Aug 31 03:00:12 ovpn-client1[1302]: Attempting to establish TCP connection with [AF_INET]X.X.X.X:443
Aug 31 03:00:12 openvpn-routing: Routing Device X from 192.168.2.105 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 1 from 192.168.2.32 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 2 from 192.168.2.178 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 3 from 192.168.2.227 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 4 from 192.168.2.127 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 5 from 192.168.2.201 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 6 from 192.168.2.234 to any through ovpnc1
Aug 31 03:00:12 ovpn-client1[1302]: ovpn-route-pre-down tun11 1500 0 10.8.0.2 255.255.255.0 init
Aug 31 03:00:12 ovpn-client1[1302]: Closing TUN/TAP interface
Aug 31 03:00:12 ovpn-client1[1302]: /usr/sbin/ip addr del dev tun11 10.8.0.2/24
Aug 31 03:00:12 ovpn-client1[1302]: ovpn-down 1 client tun11 1500 0 10.8.0.2 255.255.255.0 init
Aug 31 03:00:12 ovpn-client1[1302]: SIGTERM[hard,init_instance] received, process exiting
Aug 31 03:00:13 openvpn-routing: Clearing routing table for VPN client 1
Aug 31 03:00:13 kernel: Interface tun11 doesn't exist
Aug 31 03:00:13 kernel: Interface tap11 doesn't exist
Aug 31 03:00:14 DualWAN: skip single wan wan_led_control - WANRED off
Aug 31 03:00:12 openvpn-routing: Routing Device X from 192.168.2.105 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 1 from 192.168.2.32 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 2 from 192.168.2.178 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 3 from 192.168.2.227 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 4 from 192.168.2.127 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 5 from 192.168.2.201 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 6 from 192.168.2.234 to any through ovpnc1

 

[ColinTaylor]

Yes the timing of the reboots could be the problem. Let us know how it goes.

 

[sipankh]

I decided to change the reboot times and see if that fix the issue. What do I mean by that? Well, both ends have been scheduled to reboot at the time time. Now I am changing one to reboot at 3 am and the other at 4am (different timing) to allow both ends to go through the cycle without OpenVPN client awaiting server to be ready, which I think might be the issue here. ...am not sure but that is to me logical to try.

What I see is this second after the failure to establish conenction ie the refusal (removed IP's and host names with Device X - X 6:
Aug 31 03:00:11 ovpn-client1[1302]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Aug 31 03:00:12 ovpn-client1[1302]: TCP/UDP: Preserving recently used remote address: [AF_INET]X.X.X.X:443
Aug 31 03:00:12 ovpn-client1[1302]: Socket Buffers: R=[87380->87380] S=[16384->16384]
Aug 31 03:00:12 ovpn-client1[1302]: Attempting to establish TCP connection with [AF_INET]X.X.X.X:443
Aug 31 03:00:12 openvpn-routing: Routing Device X from 192.168.2.105 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 1 from 192.168.2.32 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 2 from 192.168.2.178 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 3 from 192.168.2.227 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 4 from 192.168.2.127 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 5 from 192.168.2.201 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 6 from 192.168.2.234 to any through ovpnc1
Aug 31 03:00:12 ovpn-client1[1302]: ovpn-route-pre-down tun11 1500 0 10.8.0.2 255.255.255.0 init
Aug 31 03:00:12 ovpn-client1[1302]: Closing TUN/TAP interface
Aug 31 03:00:12 ovpn-client1[1302]: /usr/sbin/ip addr del dev tun11 10.8.0.2/24
Aug 31 03:00:12 ovpn-client1[1302]: ovpn-down 1 client tun11 1500 0 10.8.0.2 255.255.255.0 init
Aug 31 03:00:12 ovpn-client1[1302]: SIGTERM[hard,init_instance] received, process exiting
Aug 31 03:00:13 openvpn-routing: Clearing routing table for VPN client 1
Aug 31 03:00:13 kernel: Interface tun11 doesn't exist
Aug 31 03:00:13 kernel: Interface tap11 doesn't exist
Aug 31 03:00:14 DualWAN: skip single wan wan_led_control - WANRED off
Aug 31 03:00:12 openvpn-routing: Routing Device X from 192.168.2.105 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 1 from 192.168.2.32 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 2 from 192.168.2.178 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 3 from 192.168.2.227 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 4 from 192.168.2.127 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 5 from 192.168.2.201 to any through ovpnc1
Aug 31 03:00:12 openvpn-routing: Routing Device X 6 from 192.168.2.234 to any through ovpnc1

Additional info that could help - I removed the corn job for an auto reboot on the RT-AC68U side and rebooted to save the changes of removing the corn job. After reboot, even in the config option of "Automatic start at boot time" the client didn't auto-reconnect.

 

[sipankh]

Yes the timing of the reboots could be the problem. Let us know how it goes.

Yup, agreed. Will see how it goes tonight. Will report findings. Thanks.