Firmware 4.0 and Kill switch VPN

We made it bigger in firmware update!

1 Like

Super! Any hint on when the next firmware might be coming? Maybe in the stable channel? I see ATX1800 already has 4.0.2 in stable channel… :frowning:

I am using 4.1. It has a lot of changes so may be slower.

Would be nice if you guys can update the documentation on the website to reflect this change, on the website it’s still showing the old GUI kill switch way.

There is 4.0 docs VPN Dashboard - GL.iNet Docs

Update continuously.

@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?

3 Likes

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

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

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.

1 Like

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

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.”

1 Like

Nice suggestions. Thanks very much!

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.

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:

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.

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.

2 Likes

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.

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

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

Thanks hansome for this message!

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

Thanks!

Yes, this should be developed on version 4.6.

Awesome, thanks for the quick reply!