What's new

VPN Client: Is Merlin's kill switch killing too much ...

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Leguar

Occasional Visitor
RT-AX88U Merlin v. 386.2_4

As you can see, I have a VPN Client running. Service state is ON (picture 1 and 2).
Now and then I have to close the tunnel, and go back to my normal Lan.

If I disable the Service state (OFF), my whole Lan goes down and I have to reboot
the router to get connected to the internet again (without VPN).

I think, that when I decide to stop the service, the kill switch should not break in,
and turn my Lan down.
Am I right or not ?? :rolleyes:
 

Attachments

  • VPN Client 1.JPG
    VPN Client 1.JPG
    89.8 KB · Views: 183
  • VPN Client 2.JPG
    VPN Client 2.JPG
    87.6 KB · Views: 151
What do you mean by
and turn my Lan down.

?

If you mean that your clients aren’t able to contact the outside world anymore, then this is by design. If you enable the kill switch, regardless of whether you disable the tunnel or the tunnel goes down, your clients will not have internet access anymore, until you disable the kill switch. I’m not sure whether a reboot is required, it might well be that, after disabling the kill switch, re-starting and stopping the VPN client manually will suffice, but you should give that a try, cause I’m not sure.

Am I right or not ?? :rolleyes:

That depends how you look at it… :D
 
This has been discussed previously several times. That's simply the way Merlin designed it. The "kill switch" is a bit odd in that it's an option that persists regardless of the VPN status (ON or OFF). AFAIK, the only alternative if this isn't to your liking is to remember to disable the kill switch each time you disable the VPN.
 
This has been discussed previously several times. That's simply the way Merlin designed it. The "kill switch" is a bit odd in that it's an option that persists regardless of the VPN status (ON or OFF). AFAIK, the only alternative if this isn't to your liking is to remember to disable the kill switch each time you disable the VPN.
Oh my. This could be an alternative, though I still think if I decide to close the service, should overrule the kill switch.
Will test this later :)
 
Oh my. This could be an alternative, though I still think if I decide to close the service, should overrule the kill switch.
Will test this later :)

In terms of being counter-intuitive to most ppl, I agree. However, fwiw, there *is* an advantage to the current situation.

Many VPN providers find it convenient (at least from their perspective) to kick users off the VPN by forcing an AUTH FAIL (even though your authorization is perfectly valid) when their servers become overloaded, or perhaps just for unannounced maintenance (it's why you really need a watchdog process for the VPN to restart it, but that's another issue). When that happens, it causes the openvpn process itself to exit (!), which then results in the OpenVPN client status changing to OFF! If the router didn't make the kill switch persistent, then the AUTH FAIL event would result in a leak over the WAN.

IOW, the router can't distinguish between YOU turning OFF the VPN vs. having the VPN provider do so through their own actions. I suppose you could make the argument that it *should* by changing the implementation, but as of the moment, it can't.
 
Oh my. This could be an alternative, though I still think if I decide to close the service, should overrule the kill switch.
Will test this later :)
Replying to my own msg. about testing this later.
1) VPN tunnel is On - want to turn it Off
2) Setting "Block routed clients if tunnel goes down" to No - and apply setting.
3) Turn VPN tunnel Off
Result: Still no connection from Lan til Internet. And have to reboot the router.
 
Last edited:
In terms of being counter-intuitive to most ppl, I agree. However, fwiw, there *is* an advantage to the current situation.

Many VPN providers find it convenient (at least from their perspective) to kick users off the VPN by forcing an AUTH FAIL (even though your authorization is perfectly valid) when their servers become overloaded, or perhaps just for unannounced maintenance (it's why you really need a watchdog process for the VPN to restart it, but that's another issue). When that happens, it causes the openvpn process itself to exit (!), which then results in the OpenVPN client status changing to OFF! If the router didn't make the kill switch persistent, then the AUTH FAIL event would result in a leak over the WAN.

IOW, the router can't distinguish between YOU turning OFF the VPN vs. having the VPN provider do so through their own actions. I suppose you could make the argument that it *should* by changing the implementation, but as of the moment, it can't.
Make sense, but still disagree, 'cause a personal action, aka. close a VPN tunnel should override a kill switch :)
 
@Hazel
Naturally I look at it from MY thinkings ;-)
I've been through this a long while ago. Here is what I've learned (and works for me)
- rather than redirecting the whole LAN range through the tunnel I just add client IPs or CIDRs to the OVPN client of choice
- to avoid rebooting the router when turning the client off, remove the clients from the routing rules table, turn the killswitch off and restart the client (CLI is faster) Then the reverse the motion to turn on.
- leave the routing rules table empty and use selective routing through the respective client, then turning the client off will not affect your connectivity.

It all depends on what best suits your use case(s)...
 
I've had lots of problems with trying to use a VPN as well (in my case, Surfshark/OpenVPN). My Amazon Fire TV Sticks have been particularly troublesome if trying to use them with the VPN set up on my RT-AX88U. The last time I tried adding them to the routing table, they refused to use the VPN using either of the policy rules options and with the "Accept DNS Configuration" set to Exclusive (or any other setting for that matter). The only thing that worked was setting "Force Internet traffic through tunnel" to "Yes", but then I found that when I set it back to "No", the Fire TV Sticks were still showing as being connected to the VPN. Perhaps VPN really stands for Virtual Problematic Network!
 
When that happens, it causes the openvpn process itself to exit (!), which then results in the OpenVPN client status changing to OFF! If the router didn't make the kill switch persistent, then the AUTH FAIL event would result in a leak over the WAN.

What's not right in my opinion is the kill switch remains active even after client reset. This client doesn't exist anymore. Reboot restores the WAN access. A message in UI explaining what needs to be done would save time and wondering what's going on.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top