Suggestion* Killswitch for VPN when VPN is disabled

Technical Support for Routers
1

I have the same desire as other users on this forum with regards to the "Killswitch" functionality.

If I am using policy based routing (allowing only certain Mac addresses to access the VPN) I assume that if the Wireguard client was disabled (turned off) then the the policy based devices that are specified to go via the VPN would NOT hit the clearnet (WAN) that to me is a Killswitch.

However, if the Wireguard client has been disabled / turned off then devices will use the WAN, only when the Wireguard client is ENABLED will the devices have a "Killswitch" as apparently if the tunnel goes down / connection is lost to the VPN (not the actual wireguard client getting disabled in the GUI) then the devices won't route, by using that approach though I don't feel very comfortable as i cant replicate the tunnel going down to see if it does indeed stop the device going via WAN, also if I accidentally turn off the Wireguard Client then I will be unknowingly allowing my VPN device over WAN until I realise.

After some digging I found this thread: Is it possible to block-non vpn traffic on specific device (MAC address) - #11 by T309

In particular the code that was used:

Iptables -I FORWARD -m mac --mac-source 66:2D:BF:64:EA:62 ! -o wgclient -j DROP

I used that code in my Luci config and edited the Mac addresses of that are using my policy based routing to use the VPN.

By using that code I can now be sure that if the Wireguard client gets turned off by user intervention in the GUI that the devices won't go out via WAN, works great and that's my definition of a Killswitch and being able to see it in action.

There is the "block non VPN traffic" rule but that rule effects every client on the Lan when the client goes offline so that's pretty pointless when using policy based routing.

So with all that said, is there a way we can have the default behaviour (or a checkbox / toggle) that will actually implement a "VPN Killswitch" maybe by using the command that was shared.

For anyone that wants to disable WAN traffic over VPN clients when the VPN client is disabled then just scroll up and adjust the command to your clients Mac address and then add the rule to (Luci) Network > Firewall > custom rules

2

The VPN killswitch works fine already. You can simply test it by revoke the wireguard keys - internet will stop then.

Disabling the VPN isn't the same like „the VPN stopped“

3

Personnaly I don't clearly understand in how a killswitch is different than the firewall rules as :

  • deny outgoing all
  • deny incoming all
  • allow out anywhere on tun0

rules for ufw on Linux Mint
In addition I have some local DNS resolver (Unbound) so that if the firewall was bypassed, anyway Unbound is disabled by my vpnstart script after the tun0 connection is on. Perhaps I could call this a double killswitch.

4

Ok but what about an option on the gui that stops any WAN traffic over the policy routed Mac addresses when the Wireguard client is disabled.

I understand the Killswitch will activate if the tunnel goes down however that's not what I'm proposing. My problem is if the Wireguard client isn't enabled and I have policy based Mac rules for devices to go via the VPN then that should take priority and block any access to WAN even if the Wireguard client has been disabled / toggled off by the user.

Take this example. I have a device policy routed to the connected VPN client and it's currently running, I toggle off the Wireguard client and then I load another request on the device that should be going via the VPN policy, well that won't happen, It will then just revert to using wan and the end user wouldn't even know. So another option in the GUI to double down the outgoing VPN clients and stop ANY traffic over the wan if they are selected to be policy routed would be ideal.

I guess that the device probably doesn't understand / read the list inside the Wireguard policy routing when the Wireguard client is disabled, hence it then ignores the policy routing and goes via WAN but having the list read somehow even when then wireguard client is disabled would get around that I guess.