What’s best, a merlin kill switch or a socks5 proxy acting as a kill switch?

[RFT354]

Which one is most reliable? I assume the Merlin kill switch works by checking every few seconds if there’s a VPN connection, so in that sense the proxy should be more reliable, but does the proxy have negative sides the router-based kill switch doesn’t have? Does the proxy interfere with the VPN?

SOCKS5 proxy

Use our SOCKS5 proxies to further minimize your computer's identity from being revealed and reduce CAPTCHAs.

mullvad.net

 

[eibgrad]

As described in that link, the proxy is necessarily a per-client configuration (unless you intend to configure it as a transparent proxy on the router). So if you're configuring the OpenVPN client on the router, I don't find it all that convenient. That aside, in principle, it's pretty straight-forward; if the VPN is down, so is the proxy.

One weakness in the OpenVPN client kill switch is *perhaps* a small window of opportunity between the time the VPN goes down, and when the router recognizes that fact and blocks the routing table. But that's why I'd rather implement my own kill switch which is NOT conditional on the state of the OpenVPN client.

WAN_IF="$(ip route | awk '/^default/{print $NF}')"
iptables -I FORWARD -o $WAN_IF -j REJECT

In my example, I'm blocking access to the WAN for *all* clients, under the assumption that all clients are being forced over the VPN (i.e., no PBR (policy based routing)). But you could modify it and have it apply to those specific clients using PBR. Yes, a bit less convenient than having the GUI handle the kill switch for you, but at least it's *always* in effect and eliminates that window of opportunity (however narrow).

On a side note, realize that the router does NOT offer a kill switch unless you're using PBR! In that situation, either the proxy or your own kill switch become necessary.

 

[RFT354]

I’m only interested in the proxy-as-a-kill-switch solution if I can configure the router for both OpenVPN client and socks5 proxy, so I don’t have to configure every app on every computer and device connected to the router.

I’ll mail Mullvad on Monday and ask how to configure a router with their VPN and proxy. I mailed NordVPN and they said they don’t have socks5 proxy as a kill switch, and neither does ProtonVPN. Maybe Mullvad is alone?


“On a side note, realize that the router does NOT offer a kill switch unless you're using PBR! In that situation, either the proxy or your own kill switch become necessary.”

I don’t understand. Are you saying simply turning on the Merlin built-in kill switch is not enough? Is PBR done in the router or in the apps?


I’m truly out of my depth when I’m in these snb forums. I understand perhaps 10%-20% of what you people are writing. Pasting code is too difficult for me, since I don’t even know where to insert it and how, but I’ll bookmark your code in case I need it in the future.

 

[eibgrad]

I’m only interested in the proxy-as-a-kill-switch solution if I can configure the router for both OpenVPN client and socks5 proxy, so I don’t have to configure every app on every computer and device connected to the router.

I’ll mail Mullvad on Monday and ask how to configure a router with their VPN and proxy. I mailed NordVPN and they said they don’t have socks5 proxy as a kill switch, and neither does ProtonVPN. Maybe Mullvad is alone?

Frankly, this is the only time I've heard of an OpenVPN provider providing that option. And it's not an option I've sought out in the past, so I can't comment one way or the other regarding how common it is.

“On a side note, realize that the router does NOT offer a kill switch unless you're using PBR! In that situation, either the proxy or your own kill switch become necessary.”

I don’t understand. Are you saying simply turning on the Merlin built-in kill switch is not enough? Is PBR done in the router or in the apps?

PBR is implemented on the router. You enable it in the OpenVPN client GUI using the "Force Internet traffic through tunnel" option (near the bottom). If you select either Policy Rules or Policy Rules (strict), then it becomes possible to add rules (further below) to define which IPs are routed over the VPN. Anything NOT specified in those rules remains bound to the WAN.

But notice the option "Block routed clients if tunnel goes down" (i.e., the kill switch) only appears when you enable PBR! But suppose you decide you don't need/want PBR, and just want *everything* routed over the VPN (which is the default behavior). In that one particular configuration, the GUI does NOT offer a kill switch! But a kill switch is just as valid and necessary a consideration in that configuration as when using PBR.

IMO, that's a mistake (or at least a shortcoming) in the GUI that needs to be corrected. What other members will tell you to get around the problem is to *always* enable PBR, even if that means explicitly forcing all clients over the VPN (e.g., source IP = 192.168.1.0/24), and thus making the kill switch always available. But the problem w/ that strategy is that PBR necessarily takes the router itself off the VPN, which can be problematic. For example, you can end up w/ a DNS leak if the OpenVPN provider pushes a *public* DNS server rather than one within the same scope as the tunnel! That's why I suggest when NOT using PBR that you add your own kill switch (as I described in my prior post) and thus keep the router itself bound to the VPN.

I’m truly out of my depth when I’m in these snb forums. I understand perhaps 10%-20% of what you people are writing. Pasting code is too difficult for me, since I don’t even know where to insert it and how, but I’ll bookmark your code in case I need it in the future.

I understand your frustration. This stuff can get quite complex. I often wonder how anyone who is NOT in the industry, just your average consumer, could be expected to absorb all of it. And that's why we have a GUI; to simplify things. But inevitably users come along who want something the GUI doesn't offer, or who believe something can be done better (e.g., using a proxy as your kill switch). But that's going to necessarily add complexity to a situation where you may already be overwhelmed. And that's why many ppl are better off to leave well enough alone and take what the router offers.

 

[RFT354]

I got answer from Mullvad and they wrote most users they've seen use the SOCKS5 proxy on their end devices and the VPN directly on their router, and that they’ve never seen routers where you can set both the VPN and proxy on the router.

Do you know if the RT-AC86U stock or Merlin supports setting SOCKS5 proxy on the router? If it’s possible then one could perhaps have two routers connected to each other, where one has a VPN and the other proxy. If this is not possible then your code is probably the best way forward, since it doesn’t require any PBR.


“And that's why many ppl are better off to leave well enough alone and take what the router offers.”

What the router offers, with or without Merlin, is not good enough compared to the VPN desktop app, which automatically turns on the kill switch for all new downloaded apps. No user interaction required.

I think it’s odd Asus and Merlin don’t support just flipping a kill switch to ON and be done with it for all devices connected to the router. With Merlin’s solution I’m certain I won’t remember setting the PBR if I connect a new device to the router a year or two from now. Router kill switch PBR should be for exceptions, and not for inclusions of devices. It’s not intuitive.

 

[RMerlin]

But a kill switch is just as valid and necessary a consideration in that configuration as when using PBR.

That's because the killswitch is enabled implemented through PBR, hence the need to enable it for it to be available.

 

[eibgrad]

That's because the killswitch is enabled through PBR, hence the need to enable it for it to be available.

Understood. But the fact remains, the kill switch should NOT be a function of whether PBR is or isn't active, but simply whether anything (either in-full (the default) or partial (due to PBR)) is bound to the VPN. The way it works today is simply an artifact of an architectural decision made long ago that *could* be corrected. And as the OP correctly pointed out, the fact that you *must* use PBR in order to gain access to the kill switch is NOT intuitive.

 

[eibgrad]

I got answer from Mullvad and they wrote most users they've seen use the SOCKS5 proxy on their end devices and the VPN directly on their router, and that they’ve never seen routers where you can set both the VPN and proxy on the router.

Do you know if the RT-AC86U stock or Merlin supports setting SOCKS5 proxy on the router? If it’s possible then one could perhaps have two routers connected to each other, where one has a VPN and the other proxy. If this is not possible then your code is probably the best way forward, since it doesn’t require any PBR.


“And that's why many ppl are better off to leave well enough alone and take what the router offers.”

What the router offers, with or without Merlin, is not good enough compared to the VPN desktop app, which automatically turns on the kill switch for all new downloaded apps. No user interaction required.

I think it’s odd Asus and Merlin don’t support just flipping a kill switch to ON and be done with it for all devices connected to the router. With Merlin’s solution I’m certain I won’t remember setting the PBR if I connect a new device to the router a year or two from now. Router kill switch PBR should be for exceptions, and not for inclusions of devices. It’s not intuitive.

OP, given the entire situation (including by your own admission, just being able to comprehend it all), seems to me your best option is to keep things as simple as possible, and put aside this idea of the proxy. If you insist on a proxy, perhaps use it for specific devices, ones you designate as "most secure". Because most ppl seem quite satisfied w/ the available kill switch as it is (putting aside the one exception I described). So either enable PBR and specify the entire network to be routed over the VPN, or just use my suggested kill switch.

An alternative to my suggested kill switch (brought to my attention by another member) would be to create an appropriate Network Services Filter (see Firewall) to accomplish the same thing. The only caveat w/ using Network Services Filter is that it is limited to the TCP and UDP protocols, while my kill switch has no such limitation; everything gets blocked (whether that difference matters is up to you). But either way, at least this keeps the router itself on the VPN at all times.

 

[RMerlin]

Understood. But the fact remains, the kill switch should NOT be a function of whether PBR is or isn't active, but simply whether anything (either in-full (the default) or partial (due to PBR)) is bound to the VPN. The way it works today is simply an artifact of an architectural decision made long ago that *could* be corrected. And as the OP correctly pointed out, the fact that you *must* use PBR in order to gain access to the kill switch is NOT intuitive.

There was actually a typo, what I meant was that the killswitch is implemented through PBR. To work, PBR tables must be created, with rules copied to these tables, and these tables' default gateway be modified when the route goes down (changing it to "prohibit"). That's why policy routing must be enabled, killswitch IS a policy route in itself.

 

[RFT354]

There was actually a typo, what I meant was that the killswitch is implemented through PBR. To work, PBR tables must be created, with rules copied to these tables, and these tables' default gateway be modified when the route goes down (changing it to "prohibit"). That's why policy routing must be enabled, killswitch IS a policy route in itself.

I’m giving up on the proxy idea, but why can’t you just integrate eibgrad’s code and have it as a default option in the GUI without the PBR having to be enabled? Is that not possible?

 

[L&LD]

Did you not read the post you quoted?

In any case, I am sure RMerlin will 'fix' this, if possible.

 

[RFT354]

Did you not read the post you quoted?

In any case, I am sure RMerlin will 'fix' this, if possible.

I don’t know anything about coding, but if eibgrab’s code works the way he claims, then my question is relevant.

I’m not demanding anything. Just want to know the logic behind certain decisions.

 

[L&LD]

I have no doubts about @eibgrad's or @RMerlin's code quality. I don't have any coding skills either, nor do I think you demanded anything.

But one is not related to the other. As stated in @eibgrad's post and in @RMerlin's too.

 

[RFT354]

I have no doubts about @eibgrad's or @RMerlin's code quality. I don't have any coding skills either, nor do I think you demanded anything.

But one is not related to the other. As stated in @eibgrad's post and in @RMerlin's too.

Ok, I’m dropping it …

 

[L&LD]

Dropping what? Did we learn anything yet?