VPN Request for 380.xx

[Model3CA]

I just recently stumbled on Merlin, and LOVE that it's not a wholesale firmware replacement. I have a VPN provider, and configured my router as a client yesterday and it was up and running. This morning I check, and for some reason it is disabled. So two improvements I'd like to see:

1) On the VPN status, show 'uptime' of the tunnel
2) Be more aggressive in reconnecting to the VPN server

I'm connected to the same VPN server via a desktop client, and it didn't drop during the time the router did. So I don't know what happened.

 

[Model3CA]

Perused the logs, and found this, which appears to be the VPN disconnection event. Like I said, my desktop VPN client which routes through the Asus did NOT disconnect at any time.

Jul 29 19:58:03 openvpn[6410]: write UDP: Network is unreachable (code=101)
Jul 29 19:58:04 watchdog: restart httpd
Jul 29 19:58:04 rc_service: watchdog 483:notify_rc stop_httpd
Jul 29 19:58:04 rc_service: waitting "restart_net_and_phy" via ...
Jul 29 19:58:06 WAN_Connection: WAN was exceptionally disconnected.
Jul 29 19:58:06 RT-AC68U: start httpd - SSL
Jul 29 19:58:06 RT-AC68U: start httpd
Jul 29 19:58:07 kernel: gro enabled with interval 2
Jul 29 19:58:08 Samba_Server: daemon is started
Jul 29 19:58:08 rc_service: watchdog 483:notify_rc start_httpd
Jul 29 19:58:08 RT-AC68U: start httpd - SSL
Jul 29 19:58:08 RT-AC68U: start httpd
Jul 29 19:58:10 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Jul 29 19:58:11 WAN_Connection: WAN was restored.
Jul 29 19:58:11 rc_service: udhcpc 29143:notify_rc stop_vpnclient1
Jul 29 19:58:12 rc_service: udhcpc 29143:notify_rc stop_upnp
Jul 29 19:58:12 rc_service: waitting "stop_vpnclient1" via udhcpc ...
Jul 29 19:58:12 openvpn[6410]: event_wait : Interrupted system call (code=4)
Jul 29 19:58:12 openvpn[6410]: vpnrouting.sh tun11 1500 1542 10.9.0.22 10.9.0.21 init
Jul 29 19:58:12 openvpn-routing: Configuring policy rules for client 1
Jul 29 19:58:13 openvpn-routing: Flushing client routing table
Jul 29 19:58:13 openvpn-routing: Completed routing policy configuration for client 1
Jul 29 19:58:13 openvpn[6410]: /usr/sbin/ip route del 10.9.0.1/32
Jul 29 19:58:13 openvpn[6410]: ERROR: Linux route delete command failed: external program exited with error status: 2
Jul 29 19:58:13 openvpn[6410]: /usr/sbin/ip route del 173.254.208.98/32
Jul 29 19:58:13 openvpn[6410]: ERROR: Linux route delete command failed: external program exited with error status: 2
Jul 29 19:58:13 openvpn[6410]: /usr/sbin/ip route del 0.0.0.0/1
Jul 29 19:58:13 openvpn[6410]: ERROR: Linux route delete command failed: external program exited with error status: 2
Jul 29 19:58:13 openvpn[6410]: /usr/sbin/ip route del 128.0.0.0/1
Jul 29 19:58:13 openvpn[6410]: ERROR: Linux route delete command failed: external program exited with error status: 2
Jul 29 19:58:13 openvpn[6410]: Closing TUN/TAP interface
Jul 29 19:58:13 openvpn[6410]: /usr/sbin/ip addr del dev tun11 local 10.9.0.22 peer 10.9.0.21
Jul 29 19:58:13 openvpn[6410]: SIGTERM[hard,] received, process exiting
Jul 29 19:58:14 rc_service: udhcpc 29143:notify_rc start_upnp

 

[RMerlin]

On the VPN status, show 'uptime' of the tunnel

Not doable, because the firmware isn't always aware of disconnection/re connection event that happen within the openvpn client and don't involve a complete client restart.

Be more aggressive in reconnecting to the VPN server

Connection retries are already configurable.

 

[RMerlin]

Perused the logs, and found this, which appears to be the VPN disconnection event. Like I said, my desktop VPN client which routes through the Asus did NOT disconnect at any time.

You just didn't see it happen, because your whole Internet connection went down:

Jul 29 19:58:06 WAN_Connection: WAN was exceptionally disconnected.

So if your desktop client claimed to remain connected, it lied - you had no Internet connection at all during that time.

 

[Model3CA]

Not doable, because the firmware isn't always aware of disconnection/re connection event that happen within the openvpn client and don't involve a complete client restart.



Connection retries are already configurable.

I mis-understood what the retry description was conveying. My quick reading of the description lead me to believe "-1" would retry infinitely to reconnect. Would make more sense (to me) to say "-1 to disable retry". Thanks for pointing that option out.

 

[MarioCaires]

I mis-understood what the retry description was conveying. My quick reading of the description lead me to believe "-1" would retry infinitely to reconnect. Would make more sense (to me) to say "-1 to disable retry". Thanks for pointing that option out.

-1 is infinite
0 is disabled

 

[Model3CA]

-1 is infinite
0 is disabled

Now I'm even more confused. With "-1" I woke up this morning and my VPN client was "off", but last night I left it in the "on" status. If "-1" is infinite retry, then shouldn't it attempt to reconnect after some period of time, indefinitely until it does connect successfully? I manually clicked "on" and it immediately connected. So the "infinite" retry didn't appear to retry for me.

 

[Model3CA]

Any update here to help clear up my confusion about -1 and it appearing to not retry?

 

[Zirescu]

Do you keep losing your WAN connection? And do you have the Start with WAN set to Yes? Any custom configuration options specified? Could be the VPN provider dropping you as well.