Killswitch not functioning correctly

[theinfinityjoe]

i set up policy rules strict, set block access to yes and added my subnet (192.168.4.0/24) to the rules but a small handful of websites are still loading when the vpn is not active, all load with the vpn turned on ... i'm using the latest version of merlin, any idea what could be wrong ?

 

[eibgrad]

AFAIK, the VPN is suppose to block access when the VPN *fails* (i.e., still activated, turned ON), NOT when deactivated, as in turned OFF.

 

[Martineau]

i set up policy rules strict, set block access to yes and added my subnet (192.168.4.0/24) to the rules but a small handful of websites are still loading when the vpn is not active, all load with the vpn turned on ... i'm using the latest version of merlin, any idea what could be wrong ?

Selective routing only works with IPv4.

If you are using IPv6, then the IPv6 website will bypass the IPv4 Kill-switch.

 

[Martineau]

AFAIK, the VPN is suppose to block access when the VPN *fails* (i.e., still activated, turned ON), NOT when deactivated, as in turned OFF.

Incorrect.

NOTE: Sadly @RMerlin also made a recent change

386.1 (30-Jan-2021)
  - CHANGED: At boot time, OpenVPN killswitch will only be
             applied for clients set to auto-start with WAN.

So even if the VPN Client is fully configured but isn't marked 'Start with WAN=YES' during the boot, if it is a local requirement to explicitly delay the initialisation i.e. only start the VPN Client say from within nat-start, then this Kill-switch is NOT applied leaving a short period of exposure via the WAN.

 

[eibgrad]

Incorrect.

NOTE: Sadly @RMerlin also made a recent change

386.1 (30-Jan-2021)
  - CHANGED: At boot time, OpenVPN killswitch will only be
             applied for clients set to auto-start with WAN.

So even if the VPN Client is fully configured but isn't marked 'Start with WAN=YES' during the boot, if it is a local requirement to explicitly delay the initialisation i.e. only start the VPN Client say from within nat-start, then this Kill-switch is NOT applied leaving a short period of exposure via the WAN.

Well now that change by @RMerlin sort of makes sense, at least to me (I assume by your comments you don't like it). It appears he's recognizing there may be ppl who do NOT want the kill switch applied if the VPN is inactive (as in OFF). They may simply NOT be using it for whatever reasons. It's considered dormant. But I can also appreciate this concern for a short period of exposure for those who choose their own OpenVPN client startup method. But even prior to this change, I wonder if there wasn't still a period of exposure. When it comes to timing on these routers, it's pretty difficult to eliminate all such windows of opportunity. Not without extraordinary effort.

I suppose the 64k question is what the OP means by "not active" and whether this change is relevant to his problem.

 

[RMerlin]

The change was made because when someone disables Start at WAN, they usually expect that client config to no longer have any impact at all on their network, because for the majority of users, this is equivalent to completely disabling that client.

 

[Martineau]

The change was made because when someone disables Start at WAN, they usually expect that client config to no longer have any impact at all on their network, because for the majority of users, this is equivalent to completely disabling that client.

So you now have a confusing "apply Kill-switch sometimes" scenario.

Surely the intent of enabling a Kill-switch implies that if the VPN Client isn't UP under any circumstance, then prevent the nominated LAN clients from accessing the WAN.

Clearly there is a non-ambiguous solution i.e. simply inform the user to explicitly set Block routed clients if tunnel goes down=NO rather than second-guess what you think the user expects.

 

[eibgrad]

So you now have a confusing "apply Kill-switch sometimes" scenario.

Surely the intent of enabling a Kill-switch implies that if the VPN Client isn't UP under any circumstance, then prevent the nominated LAN clients from accessing the WAN.

Clearly there is a non-ambiguous solution i.e. simply inform the user to explicitly set Block routed clients if tunnel goes down=NO rather than second-guess what you think the user expects.

I understand what you're saying, but I wouldn't say that prior to this change things lacked confusion. Not everyone is going to assume a VPN that's not active (OFF) would still be enforcing the kill switch. I personally don't find it intuitive (to *me*, OFF means the VPN should have NO IMPACT of any kind), but I can at least see where some ppl might have a different interpretation.

Frankly, this kill switch stuff has several confusing aspects. For example, I still don't like the fact I can't have a kill switch unless I use PBR! For me *that* is confusing, but I understand why based on previous comments by @RMerlin; it's an unfortunate artifact of the implementation.

Anyway, as you suggest, I suppose having the user reconfigure the OpenVPN client in this regard is a possible solution. But that assumes the user has the same interpretation as you regarding how it should/does work. But I can at least see the rationale for the change based on @RMerlin's last post. This seems like one of those areas where what makes sense is highly subjective and unlikely to reach consensus.