AC-68U: connection dies when disabling vpn-client

[Calathia]

I have VPN service which I use sometimes. When I enable it, no problemo. When I disable it, connection stops working. It doesnt give any 404 or any other error, it just wont work. This has been for 2 years now, even if I update merlin everytime there is an update.

Router: Asus AC-68U, merlin 384.3

Any ideas how to fix this? Here is example log when I disable VPN:

Sep 25 20:20:53 rc_service: httpd 275:notify_rc stop_vpnclient1
Sep 25 20:20:54 ovpn-client1[14168]: event_wait : Interrupted system call (code=4)
Sep 25 20:20:54 ovpn-client1[14168]: SIGTERM received, sending exit notification to peer
Sep 25 20:20:57 ovpn-client1[14168]: vpnrouting.sh tun11 1500 1585 X.X.X.X 255.255.255.0 init
Sep 25 20:20:57 openvpn-routing: Configuring policy rules for client 1
Sep 25 20:20:57 openvpn-routing: Tunnel down - VPN client access blocked
Sep 25 20:20:57 ovpn-client1[14168]: /usr/sbin/ip route del X.X.X.X/32
Sep 25 20:20:57 ovpn-client1[14168]: /usr/sbin/ip route del 0.0.0.0/1
Sep 25 20:20:57 ovpn-client1[14168]: ERROR: Linux route delete command failed: external program exited with error status: 2
Sep 25 20:20:57 ovpn-client1[14168]: /usr/sbin/ip route del 128.0.0.0/1
Sep 25 20:20:57 ovpn-client1[14168]: ERROR: Linux route delete command failed: external program exited with error status: 2
Sep 25 20:20:57 ovpn-client1[14168]: Closing TUN/TAP interface
Sep 25 20:20:57 ovpn-client1[14168]: /usr/sbin/ip addr del dev tun11 X.X.X.X1/24
Sep 25 20:20:57 ovpn-client1[14168]: updown.sh tun11 1500 1585 X.X.X.X 255.255.255.0 init
Sep 25 20:20:58 rc_service: service 4840:notify_rc updateresolv
Sep 25 20:20:58 rc_service: waitting "stop_vpnclient1" via httpd ...

Note1: last line of above log sits there forever and does not advance from that
Note2: X.X.X.X are just my cencor for ip stuff

 

[RMerlin]

That's normal, you've configured your VPN client to block Internet access when the tunenl is down:

Sep 25 20:20:57 openvpn-routing: Tunnel down - VPN client access blocked

 

[Calathia]

That's normal, you've configured your VPN client to block Internet access when the tunenl is down:

Hmm, that is pretty interesting.... Obviosly blocking internet access in viable to the security, but there is a big difference between tunnel being down (VPN operator may have issues, etc) or merlin user activated vpn disable. Its like owning a car with anti theft mechanism and it alarms every time you open a car with your own key...

Is there some option that I have missed? Like "dont block access on user activated VPN disabling" or alike? Restarting router every time i disable VPN seems quite silly.

 

[Martineau]

Hmm, that is pretty interesting.... Obviosly blocking internet access in viable to the security, but there is a big difference between tunnel being down (VPN operator may have issues, etc) or merlin user activated vpn disable. Its like owning a car with anti theft mechanism and it alarms every time you open a car with your own key...

Is there some option that I have missed? Like "dont block access on user activated VPN disabling" or alike? Restarting router every time i disable VPN seems quite silly.

PEBCAK?

Have you tried simply using the VPN Client GUI option 'Redirect Internet traffic=ALL '? - which by design, doesn't offer the option to 'Block routed clients if tunnel goes down', but if the VPN Client is UP ALL LAN traffic will be via the VPN tunnel, and when the VPN is DOWN, traffic will revert back via the WAN interface.

This is the equivalent of 'Redirect Internet traffic=Policy' or 'Redirect Internet traffic=Policy (Strict)' with the LAN subnet defined in the Selective Routing table:

LAN   xxx.xxx.xxx.1/24   0.0.0.0   vpn

and obviously 'Block routed clients if tunnel goes down=NO'

P.S. There are excellent guides by @yorgi and @Xentrk to help you understand the VPN Client GUI options.

 

[Calathia]

PEBCAK?

Have you tried simply using the VPN Client GUI option 'Redirect Internet traffic=ALL '? - which by design, doesn't offer the option to 'Block routed clients if tunnel goes down', but if the VPN Client is UP ALL LAN traffic will be via the VPN tunnel, and when the VPN is DOWN, traffic will revert back via the WAN interface.

This is the equivalent of 'Redirect Internet traffic=Policy' or 'Redirect Internet traffic=Policy (Strict)' with the LAN subnet defined in the Selective Routing table:

LAN   xxx.xxx.xxx.1/24   0.0.0.0   vpn

and obviously 'Block routed clients if tunnel goes down=NO'

P.S. There are excellent guides by @yorgi and @Xentrk to help you understand the VPN Client GUI options.

Thank you Marin for your insight. Unfortunately your method does not suite to me as only one assigned IP uses the VPN. Is there another way to get this to work?

 

[M@rco]

I have the following setup (but then exactly the other way around) to make sure my router is accessible on the WAN interface.

Set 'Redirect Internet traffic' to 'Policy (Strict)'

Set the routing table to:

LAN           192.168.1.0/24      0.0.0.0   WAN
CLIENT        ip.of.your.device   0.0.0.0   VPN

Replace 192.168.1.* with your own local IP range and set 'Block routed clients if tunnel goes down' to 'No'.

If I'm correct this should cause all clients to be routed through WAN except for the one IP you excluded (CLIENT). When the VPN drops for whatever reason, the client will be re-routed through WAN though.

 

[Martineau]

I have the following setup (but then exactly the other way around) to make sure my router is accessible on the WAN interface.

Set 'Redirect Internet traffic' to 'Policy (Strict)'

Set the routing table to:

LAN           192.168.1.0/24      0.0.0.0   WAN
CLIENT        ip.of.your.device   0.0.0.0   VPN

Replace 192.168.1.* with your own local IP range and set 'Block routed clients if tunnel goes down' to 'No'.

If I'm correct this should cause all clients to be routed through WAN except for the one IP you excluded (CLIENT). When the VPN drops for whatever reason, the client will be re-routed through WAN though.

By default an empty GUI tables means ALL LAN clients remain routed via the WAN and you only need to add entries for devices that must be explicitly routed via the VPN Client.
e.g. the statement is technically redundant for your example

LAN           192.168.1.0/24      0.0.0.0   WAN

 

[Martineau]

Thank you Marin for your insight. Unfortunately your method does not suite to me as only one assigned IP uses the VPN. Is there another way to get this to work?

Apologies I misread

Sep 25 20:20:57 ovpn-client1[14168]: /usr/sbin/ip addr del dev tun11 X.X.X.X1/24

and missed

Sep 25 20:20:57 ovpn-client1[14168]: /usr/sbin/ip route del X.X.X.X/32

So your original single entry in the GUI table is correct providing you use 'Block routed clients if tunnel goes down=NO'

 

[M@rco]

By default an empty GUI tables means ALL LAN clients remain routed via the WAN and you only need to add entries for devices that must be explicitly routed via the VPN Client.
e.g. the statement is technically redundant for your example

LAN 192.168.1.0/24 0.0.0.0 WAN

Ah, I see. Makes perfect sense actually. Thanks, learned another thing today

 

[Calathia]

Apologies I misread

Sep 25 20:20:57 ovpn-client1[14168]: /usr/sbin/ip addr del dev tun11 X.X.X.X1/24

and missed

Sep 25 20:20:57 ovpn-client1[14168]: /usr/sbin/ip route del X.X.X.X/32

So your original single entry in the GUI table is correct providing you use 'Block routed clients if tunnel goes down=NO'

Hmmm.. Block routed clients if tunnel goes down=YES is quite important feature to me, as I am using my companys laptop @ home. If my VPN service goes down (as it does time to time), I NEED to know about this.

So apparently it is not possible to circumfeit this problem? Why not add feature "Dont block routed clients on su activated tunnel disable" or something alike to Merlin?

 

[Martineau]

Hmmm.. Block routed clients if tunnel goes down=YES is quite important feature to me, as I am using my companys laptop @ home. If my VPN service goes down (as it does time to time), I NEED to know about this.

So apparently it is not possible to circumfeit this problem? Why not add feature "Dont block routed clients on su activated tunnel disable" or something alike to Merlin?

So just to clarify your requirements, you have a single LAN device that must only access the Internet via the VPN Client and should the VPN Client connection terminate unexpectedly, the LAN device must be BLOCKED from using the WAN, but should you choose to manually terminate the VPN Client connection, the LAN device should now seemingly be allowed to use the WAN - correct?

To achieve this you will need to use scripting (a couple of lines? ) as currently the firmware has no reliable way of differentiating between an abnormal vs, controlled VPN Client termination, but you could exploit say the openvpn-event 'route-down' script or basically modify a standalone script (VPN_Switch.sh) such that when it calls 'service stop vpnclientX' it adds any of the following additional custom scripting options:

1. Delete the appropriate RPDB rule (ip rule del prio nnnnn)
or
2. Bypass the insertion of the 'default prohibit' rule (see script '/usr/sbin/vpnrouting.sh')
or
3. Even more drastic - simply delete the entire ovpncX routing table.

NOTE: Ideally implement a nice noob user-friendly option i.e. patch the GUI to indicate that the VPN OFF/DOWN/APPLY GUI button has been physically pressed, then call one of the scripting methods outlined above.

 

[Calathia]

So just to clarify your requirements, you have a single LAN device that must only access the Internet via the VPN Client and should the VPN Client connection terminate unexpectedly, the LAN device must be BLOCKED from using the WAN, but should you choose to manually terminate the VPN Client connection, the LAN device should now seemingly be allowed to use the WAN - correct?

Yes, this is correct.

To achieve this you will need to use scripting (a couple of lines? ) as currently the firmware has no reliable way of differentiating between an abnormal vs, controlled VPN Client termination, but you could exploit say the openvpn-event 'route-down' script or basically modify a standalone script (VPN_Switch.sh) such that when it calls 'service stop vpnclientX' it adds any of the following additional custom scripting options:

1. Delete the appropriate RPDB rule (ip rule del prio nnnnn)
or
2. Bypass the insertion of the 'default prohibit' rule (see script '/usr/sbin/vpnrouting.sh')
or
3. Even more drastic - simply delete the entire ovpncX routing table.

NOTE: Ideally implement a nice noob user-friendly option i.e. patch the GUI to indicate that the VPN OFF/DOWN/APPLY GUI button has been physically pressed, then call one of the scripting methods outlined above.

my jffs/scripts folder is empty, so I cannot locate VPN_switch.sh

Do you know if there is different routines when tunnel goes down OR user triggers ON -> OFF switch in given VPN Client (1 to 5). Because if there is dedicated routine when user toggless ON -> OFF then simply modifying code NOT to block traffic in this specific action fixes the problem I have.

This probably is same thing that you suggested in option 1, 2 or 3 ?

 

[Martineau]

my jffs/scripts folder is empty, so I cannot locate VPN_switch.sh

The /jffs/scripts folder will not contain any (end-user/owner) custom scripts until you manually create them. The VPN_Switch.sh link was simply an example to illustrate what would need to be considered when creating your custom script.

Do you know if there is different routines when tunnel goes down OR user triggers ON -> OFF switch in given VPN Client (1 to 5).

There are several unique event triggers for OpenVPN Client 'UP,DOWN...CONNECTING/DISCONNECTING' state changes, but as previously explained, these events cannot determine if they were triggered by a GUI action.

This probably is same thing that you suggested in option 1, 2 or 3 ?

Yes.

 

[Calathia]

The /jffs/scripts folder will not contain any (end-user/owner) custom scripts until you manually create them. The VPN_Switch.sh link was simply an example to illustrate what would need to be considered when creating your custom script.

There are several unique event triggers for OpenVPN Client 'UP,DOWN...CONNECTING/DISCONNECTING' state changes, but as previously explained, these events cannot determine if they were triggered by a GUI action.


Yes.

Ok, thank you for all the help. I'll figure this out some way