Firmware 4.0 and Kill switch VPN

[alzhao]

There is 4.0 docs VPN Dashboard - GL.iNet Docs

Update continuously.

[Khell]

@alzhao Sorry but how is this change logical? Let’s recap:

• On 3.x: VPN kill switch does not affect devices excluded from the VPN using VPN Policy (and why would they; these devices are not meant for the VPN).
• On 4.x "Block Non-VPN Traffic** option completely disables Internet access for devices excluded from VPN using VPN Policy, rendering VPN Policy and this new killswitch incompatible, in other words removing functionality from the devices.

If you guys don’t intend to revert this, can you please advise us how we can achieve the same thing? Perhaps we can manually configure a new zone to put these devices under that doesn’t forward via the VPN?

[alzhao]

But you can just leave the kill switch alone. Vpn already has killswitch

[Khell]

Is this still in effect when the router is rebooted and it can’t connect to VPN?

[alzhao]

Yes it is.

VPN enabled: You will not have Internet when VPN cannot connect, disconnect or break. Only if you disable vpn, it will have normal Internet.

Disable vpn traffic (Internet killswitch): You will have no Internet if you do not use vpn.

[tame_impala]

Hi alzhao, can you confirm that the v4.x firmware will never have the Kill Switch functionality just like v3.0.

I do understand that v4.x has the “Block Non-VPN” which has higher priority than VPN Policy and if I exclude a client using VPN Policy and “Block Non-VPN” is on then I won’t have internet on this client.

I’ve been using a Flint for over an year and its working great. I connect three clients, 2 though vpn and one excluding vpn and Kill Switch work great - I lose internet on vpn clients when vpn is down and I still have internet on vpn excluding client.

I just bought a second Flint and a Mudi. If this v4.x behavior is here to stay, then unfortunately I’ll have to return these 2 new devices and will have to look into other vendors.

Also, how can I revert Flint firmware from v4.x to v3.x. Are there any docs I can follow?

Thanks

[MartinB3]

This is really too bad. I want to have a kill switch that affects all traffic but Zoom (the latency just isn’t great). I could do it in v3, but not in v4. I’d suggest improving the UI/documentation like so, to make this clearer:

“All traffic will go through the VPN” in the VPN policy should really have an asterisk that says “IF the vpn is connected. If not, this will have no effect.”

And then “Block Non-VPN Traffic” should also have an asterisk that says “DESPITE the vpn policy you’ve chosen. This will override all VPN policies and rules.”

[alzhao]

@MartinB3

“All traffic will go through the VPN” in the VPN policy should really have an asterisk that says “IF the vpn is connected. If not, this will have no effect.”

And then “Block Non-VPN Traffic” should also have an asterisk that says “DESPITE the vpn policy you’ve chosen. This will override all VPN policies and rules.”

Nice suggestions. Thanks very much!

[herds]

Firmware 4.2.3 + Kill Switch + Local network = no longer works?

This looks like the issue I have, kinda sucks I basically can’t use the internet kill switch if i need to access the lan I’m new on the forum., is this likely going to take a long time to implement? i’ve just read that i could get a different device from my slate a1300 and downgrade to a v3 firmware that was more “logical” with exceptions for VPN policies.

which is it? will we ever be able to have kill switch and access lan?

I don’t get why you would remove this and not even add it as an option. “Because its more secure” well not even using an VPN is not secure and i’m allowed to do that.

[mkdr]

Got a Brume 2 today and already have the same issue now. Making the device totally useless and am close to ship it back again:

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

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] And then enable mac address filtering for specific clients to not use VPN: [image] 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/s…

Obviously the kill switch needs to only effect the clients you set up to use the VPN. If you use a mac address filtering for clients which are excluded to use VPN, the kill switch SHALL NOT effect these.

This needs to be changed ASAP.

Either change the kill switch, or add a optional setting which kinda works like this: “exclude kill switch from policy based filtering devies which dont use the VPN”.

Also because this was already reported kinda a year ago with zero change somehow tells something about this company I guess.

This is a catastrophic fail design, especially for an advertised VPN gateway.

[hansome]

@mkdr

Obviously the kill switch needs to only effect the clients you set up to use the VPN. If you use a mac address filtering for clients which are excluded to use VPN, the kill switch SHALL NOT effect these.

I agree. We’ll consider implementing that way.

But it’s not zero change. We have weakened the role of killswitch. Its only purpose now is to make sure the traffic is not allowed if you turn off the VPN client.
Under VPN policy mode, the leak is for clients that using VPN will not happen even if you didn’t turn on kill switch. In case like server is out of service, the non-VPN traffic will be blocked by firewall(different than killswitch).
So I advise you not to turn on killswitch currently.

[mkdr]

The current implementation of the VPN policy mode is also not optimal and should be changed/extended.

First you dont see next to the mac line which mode it was, use vpn, or not use vpn. The current list is misleading. People might think they can add both at the same time, which doesnt seem to be the case, and after adding, you also dont see which it was, use VPN, or not use.

There should also be implemented an option to turn off, that all local traffic on the device itself is routed through the VPN. This causes multiple issues. for example if you want to run a proxy server on the device, to use it to bypass the VPN, doesnt work in its current state.

The VPN web gui should be extended also to include a http/https proxy on next to opnevpn, wireguard and tor, so tha proxy can run under a iptables mangle rule, to be routed directly to WAN and not VPN.

The policy rules in its current state are really simple, and need way more options.

[hansome]

@mkdr

First you dont see next to the mac line which mode it was, use vpn, or not use vpn. The current list is misleading. People might think they can add both at the same time, which doesnt seem to be the case, and after adding, you also dont see which it was, use VPN, or not use.

I have to say not intuitive enough but simpler to implement.

@mkdr

There should also be implemented an option to turn off, that all local traffic on the device itself is routed through the VPN.

Thanks for the advice, local process VPN policy we only covered goodcloud. For adgardhome, proxies, etc we will evaluate the work.

[buffer]

Thanks hansome for this message!

Do you know if this is actively being worked on already?

Thanks!

[hansome]

Yes, this should be developed on version 4.6.

[buffer]

Awesome, thanks for the quick reply!

[Sn4rF]

Devs can you please FIX this once and for all? For an advertised VPN router this is not ideal and borderline unacceptable. Thanks