VPN kill switch useless on 4.x firmware with policy based mac filtering

Technical Support for Routers
1

It seems the killswitch is totally useless on the Brume 2 with v4.4.6 firmware if you use VPN policy based on mac addresses.

If you set kill switch:

image
image1151×386 15.9 KB

And then enable mac address filtering for specific clients to not use VPN:

image
image1103×513 22.1 KB

There traffic is still blocked. This kinda makes the entire concept of kill switch and policy based routing useless. There needs to be a optional setting you can enable, “dont block for policy based clients which should not use VPN”.

Obviously it needs/should work the following:

Killswitch only blocks for all mac address you dont put in the vpn policy based routing which are excluded for using VPN. Then the clients which always use the VPN, the kill switch blocks traffic in that event until VPN is up again. All excluded LAN clients which should not use VPN should also not be blocked by the kill switch.

Is there a workaround for this?

Also the GUI for the policy based filtering is lacking information next to each MAC address if they were set to be included in VPN or not.

Seems this issue was already reported over a year ago with zero fix so far:

It seemed it worked fine on 3.x firmware and is broken since 4.x

Rendering the Brume 2 literally useless.

Is there a workaround where you maybe can add a IPTABLES rule into rc_local at boot time for specific mac address which allow wan access again?

Update:

I have added this firewall rule into /etc/config/firewall

config rule
option target ‘ACCEPT’
option src ‘lan’
option dest ‘wan’
option name ‘12 allow’
option src_ip ‘192.168.8.12’
option family ‘ipv4’
option proto ‘all’

where 192.168.8.12 is the device in my LAN, which I want to exclude using the VPN. With this rule it seems to work so far, and 192.168.8.12 can reach WAN now without using VPN, and is not blocked anymore by the kill switch rule.

Is this the right way to do this though? It would be better if GLInet would include a optional toggle you can enable under the kill switch, so you can disable the kill switch block for excluded clients not using VPN.

Or the GLInet 4.x web gui automatically adds these firewall rules for each MAC you set up in the exclude list and removes the rules again if you remove them.

2

Check this post Issue with VPN Policies + Internet Kill Switch - #4 by alzhao

And this Killswitch + VPN policy - #2 by hansome

If I understand it correct killswitch is always on automatic if the vpn connection drops your devices don’t leak.

Killswitch will not work if you disconnect yourself the vpn. I hope i understand it correct.

3
  1. this is a design issue / bug / missing feature in firmware 4.x, it worked as intended in 3.x
  2. I gave examples how GLInet can fix this in a few seconds with 2 different approaches
  3. I gave already my own workaround to this, but still asking if this is a good way to do it or not

If you enable the kill switch and use policy filtering at the same time, both concepts become non functional in firmware 4.x. The kill switch block needs to exclude the exclusion mac addresses set up by the filter policy, where it doesnt in its current implementation of 4.x scripts. It did it properly in firmware 3.x

4

We changed the design concept in 4.x as explained by Alife and Hansome. Now the Kill Switch has the highest priority to override all the rules.

1 Like
5

What is the application scenario of Using the “Kill switch” and “Mac based vpn policy”?

6

@alzhao is that a serious question? The answer is already above in my initial post.

You have n clients which are using VPN and m clients you dont want to use VPN. Obviously the kill switch is always needed and wanted for the n VPN clients, so no traffic leaks out. But at the same time you want the m clients normally work and have traffic routed through WAN.

What kind of nonsense design is that, to just have 100% clients to use VPN, or 0%. You want configure what client uses VPN including kill switch and what clients dont use VPN.

7

It’s not nonsense design, since the use-case of having some devices only VPN connected and some not is pretty rare. Normally, you would use some VPN client on the endpoint in that case. I would even say that VPN policies are more or less a gimmick than a real solution - in most cases you will go with full VPN (+ excluded domains) or VLAN based VPN.

In your case, you could either go with firewall (to block outbound traffic by this MAC via normal internet) or you could think about using VLAN / different subnet for routing. In both cases, you have to dig more into networking details - but since your use-case is special, that is what you asked for.

8

I don’t really disagree with OP, this checkbox can be a bit vague, i mean intuitively one can expect it just works some vpns also have their vanilla killswitch.

I wonder also if it is a real killswitch or more ment as a tunnel isolation :thinking:, if its tunnel isolation i guess i would like to suggest it to reword that label so its more intuitive.

9

None of those. It’s done by the firewall - so if the tunnel stops working, the traffic just drops. Should be pretty reliable in most cases.

10

Why this topic is being discussed on two different posts?!

11

But I remember last time my vpn client disconnected my devices (I use policy based routing) got blocked from the internet until I manually reconnected the vpn without activating killswitch. Is there now a build in killswitch or not?

12

I use VPN based on VLAN, so I have the VPN on my guest network, I remember seeing VPN leaks a long time ago but so far it’s been working good, I remember on version 4.1 or so you could see the leak just by rebooting the router and connecting as fast as you can to the VPN network (Guest in my case) and I was able to see my original IP on ipleak, that happens because the OpenVPN Client is starting up. I need to try again in the latest version 4.4 (On a Beryl AX).
I also tried the option to block all non VPN traffic, but blocked all non VPN clients from accessing the internet, I thought it would only affect the VPN clients.
Need to try it out because VPN leaks are annoying, I didn’t mind because I just use VPN for gaming and I barely play games nowadays