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

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

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: 58
  • VPN Client 2.JPG
    VPN Client 2.JPG
    87.6 KB · Views: 52

Hazel

Senior Member
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
 

eibgrad

Very Senior Member
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.
 

Leguar

Occasional Visitor
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 :)
 

eibgrad

Very Senior Member
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.
 

Leguar

Occasional Visitor
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:

Leguar

Occasional Visitor
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 :)
 

Torson

Senior Member
@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)...
 

TheLyppardMan

Very Senior Member
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!
 

Tech9

Very Senior Member
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.
 

Sign Up For SNBForums Daily Digest

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