[Bug][Feature Request] VPN Policies: Inability to Strictly Enforce MAC VPN Usage with Non-VPN Clients (Kill Switch)


Affected Firmware



When the GL GUI → VPN → VPN Dashboard → VPN Client tunnel/link drops for whatever reason, the VPN Policy Base On The Client Device whitelisted MAC (eg: work mobile) drops back to using clearnet. Other devices not listed to use the VPN are present using the Internet/WAN/clearnet. The expectation is that that specific VPN whitelisted MAC should have the effect of a Internet Kill Switch while the remaining clients stay on clearnet/continue using WAN as normal.

Blocking WAN access for the MAC in question via GL GUI → Clients → $device → Block WAN is reported to supersede VPN access.

I would like to request an option somewhere in the VPN Policy Base On The Client Device to strictly enforce VPN usage; that is, the MAC only uses the VPN to replicate Kill Switch functionality.


Current Solution/Workaround

See the following thread where a temporary fix/workaround is used:


If the Client devices(on “Use VPN” list) are still able to access the Internet while the VPN gets offline, then it’s a bug apparently.
I think this could be fixed without adding the “Only Use VPN” option which may add some extra complexity.

That’s exactly the reported case.

However it’s done behind the scenes works for me but I’d like to know which of my devices under a VPN policy will/will not be under a Kill Switch scenario. ‘Only use VPN’ just struck me as more in line with the existing language for such options. IDK if there’d ever be a potential use case where someone would want the VPN MAC to drop back to clearnet if the VPN goes offline but hey, “better to have it & not need it than need it & not have it”, no?

Agreed. That said, the killswitch option is for blocking traffic even if the user turns off the VPN client.
Preventing traffic leaks should be insured by some other firewall rules, not binding to the killswitch option.
I’ll do some tests on the issue.

1 Like

I’m excited to see what you come up with as a resolution.

I think I should point out I’m using ‘kill switch’ as a more of a metaphorical concept. To my limited knowledge there’s no generally accepted or industry accepted solution to ensuring all traffic is cut… or even when the strict VPN rules are in place. Eg:

1 Like

Possible option in the GUI to block all non-VPN traffic at the Policy Mode level.

Example with “Do Not Use VPN” selected:
[:ballot_box_with_check:] Block Non-VPN Traffic except as indicated below

Example with “Use VPN” selected:
[:ballot_box_with_check:] Block Non-VPN Traffic for those indicated below

That language strikes me as confusing.

  • Do Not Use VPN
    • $MAC will never use VPN
  • Only Use VPN
    • $MAC will only use VPN

Should cover both use cases, no?

So if you are selecting devices to Use VPN, “Only Use VPN” makes sense (and it could be just a 3rd option in the drop-down).

  • Only Use VPN
  • Use VPN when Available (Not really sure of the use case for this, but this is how it currently works)
  • Do Not Use VPN

It is the converse where you are selecting devices that Do Not Use VPN (and you want all other devices to only use VPN). This may be too complicated to automate, and maybe unnecessary if the first option is available.

That’s a Global Policy as it stands. Perhaps Do Not Use should supersede it.

I’m not exactly an expert but I’m rather sure iptables (soon to be nftables)/firewall rules can be chained.

1 Like

Yes, that would work if it could supercede the Global Policy.

I think I agree w/ @hansome; Use VPN when Available would lead to leaks. I’d rather it be quite explicit.

… but then again I think the GL GUI → Clients page should have icons of various states indicating these various VPN states for ‘at a glance’/overview. See the GL GUI → Internet (when WG Client or AdGuard is enabled) for the idea based off the main banner.


Is it fixed in firmware 4.2.3? Does it block the devices if vpn goes down?

Same question as Tzz, is this fixed in 4.5.6?

Also, is there any known bugs list anywhere? This could bite you real hard if you don’t know about it. Though I guess the behaviour is sort of undefined officially.