It is somewhat ambiguous ...... it needs to be updated. Apologies.
At the time this document was written, we had just added the feature to use exit nodes. What it means is that this part of the export node feature has just started to be developed and tested, and we won't add too many features at once.
The feature as an exit node is still in the pre-study stage. We're not sure exactly when it will be added, and we're not sure we'll be able to add it.
Seems the kill switch is not disable temporarily in Auto-Enable login mode, which it should.
That would make sense to me.
However, for folks who need to 100% avoid any leaks, you might consider adding an option "Allow leaks during captive portal login" in the VPN "Global Options" -> "Block Non-VPN Traffic".
Or make VPN "Global Options" have three options:
(3 would be new)
Regarding your "investigate and improve step by step", it would certainly be nice to confirm what kind of leaks could occur during the captive portal login.
If leaks can only occur to the captive portal provider, that would be less of a concern (to me anyway) than if leaks might extend further than only to the captive portal provider! Nobody wants a pseudo-security VPN that "almost works" (but is slightly leaky)!
The portal page, sometimes in the local network and sometimes in the cloud server, is the main problem.
During portal authentication stage, generally you don't have any Internet. So your data is not leaked to the Internet. But once the portal authentication is finished and there will be a very short time you have Internet. Before vpn and vpn policies are enabled again, your data maybe be leaked.
But this has been a big improvement than asking the user to disable vpn etc.
Can you add 2FA to admin panel? Or at least something like you did when accessing via DDNS.
You already have config, so why not?
And can you prevent accessing LuCi if not logged in main admin panel? Because LuCi doesnât have brute force protection.
We'll talk about that. But it doesn't make much sense locally because SSH doesn't have the ability to add 2FA.
We have no plans to maintain a separate LuCI branch. However, it might be a good idea to support a separate configuration of LuCI's access ports for this.
I meant restrict access to LuCi login if you are not logged in main (Gl) admin interface. AKA you must not be able to login into LuCi if not logged in Gl admin page.
At the very beginning we want to integrate but it will include modifying luci etc.
It does not add security as well.
But your firmware has brute force protection. LuCi doesnât (by default). So it is easiest way to protect against such attacks.
Are you exposing management interfaces to an untrusted network? Are you concerned with users on your "trusted" network?
I just need brute force protection. They protected one admin interface without protecting another. It is illogical as through LuCi there is all same configuration can be changed as from Gl interface.
Too poor security as for modified software.
On plain openwrt there is configuration to set such protection, but from Gl I expect everything work out of the box.
This also relates to Adguard Home. GL created way too much separate logins which can be abused.
I expect ONE login. Not three billion ones. None of configuration must be accessible without main admin panel.
It is like locked door without walls.
Maybe the (middle) solution would be a "Disable LUCI access" switch on main fw.
There is ONE login. It's your root login.
Different applications use different login pages. That's not because GL isn't able to provide only one login but because nearly all features are 3rd party.
No, I need LuCi. I just ask to block access to its login if not logged in main page.
You misunderstood my comment. I want to deny access to their login page if you are not logged in main admin page.
As compromise solution is implemented something like Fail2Ban to all interfaces (including LAN) to all such pages from the box.
@yuxin.zou maybe really implemented custom Fail2ban to all such pages to prevent brute force?
I clearly understand your comment. But luci is a 3rd party component - so you can't just put it behind another login page without further modification.
My advice is the same like always in those discussions: Use SSH instead. Disable luci by stopping the service and go full SSH. If you need luci, you can spin it up after connecting via SSH.
I am not CLI nerd, sorry 
I think compromise solution is to add Fail2ban to all pages from the box
But you lock your front door to keep people outside from coming in. Why are you even exposing your management interfaces to an untrusted network? If you were preventing access to your management properly, there will be nothing to bruteforce.
In this case why do you need password on admin interface? You said that it would be enough to just prevent access from untrusted networks.
Firstly, my first router (Puli) uses ârepeater modeâ often, as it is travel router. It is its purpose to connect to shady networks.
Secondly, my second router (Spitz AX) is used as home router (I hate cable connections, so cellular router). There is no connection from WAN as all cellular providers uses CGNAT.
Why just not implement Fail2ban by default to block clients that tried password too many times?
True but on WAN side none of these problems appear. WWAN and WAN are not able to connect to the GUI nor Luci.
I really don't feel you are thinking through this very well. In the first case, you are wanting to prevent bruteforcing from your own side of the repeater when traveling. Why? Are you afraid someone else will connect to your wireless network and then try to hack your router by bruteforcing your password? In the second case - even with CGNAT you should not have your mgmt network exposed.
In any case, fail2ban is available in the gl repos, you can add it yourself. Please do so and report back how it works for you. I would be curious how many IP addresses on the inside of your network end up on the failed list.
During portal authentication stage, generally you don't have any Internet. So your data is not leaked to the Internet. But once the portal authentication is finished and there will be a very short time you have Internet. Before vpn and vpn policies are enabled again, your data maybe be leaked.
True. If I am manually authenticating to the captive portal (typing in username and password), I could disconnect any devices for which such leakage might be critical.
Question: Since the intention/future implementation (as I understand it) is to allow VPN "Global Options" -> "Block Non-VPN Traffic" to be overriden when "Auto-Enable Login Mode For Public Hotspots" is enabled, could that occur at any time in the background, without the user knowing, or only when the user manually clicks the link in the router web ui to bring up the captive portal login page?
To put it another way: what triggers the "Block Non-VPN Traffic" override to start and what triggers it to stop?