[Feature request] Easily open an access to Luci from the Internet

[stokito]

Today it's not so easy for a regular user to get access to OpenWrt from the internet. Usage scenarios:

1. Remote administering: SSH access, LUCI, maybe just call Wake on Lan.
2. Collecting metrics and health checks: maybe just some endpoints.
3. Self-hosting services
   • Files: SFTP to files on a disk, WebDAV, NextCloud, Syncthing
   • Apps: Transmission, IoT hubs like HomeAssistant, email server, Docker-based services, proxy
   • VPNs

They all may have different requirements and policies. For example, if you have a Transmission UI on a separate port, then it should be generally ok to allow the WAN access. But the WAN access to Luci is potentially more dangerous. A user may want to add some restrictions like:

• IP allowlist or banip
• Use upfront external WAF and DDoS prevention services Cloudflare Proxy
• Use a Zero Trust VPNs: Cloudflare Zero Trust, ZeroTier, Tailscale etc.
• Tunnel services to bypass NAT also adds an encryption: SSH tunnels or a Tor onion service.

Some router manufactures already provide a GUI wizard to enable access from internet:

• Keenetic has an option also to get the signed cert from LetsEncrypt
• GL.iNet recommends to set up a WG VPN and use it.

From the LUCI perspective, the UI should help as much as it possible to avoid misconfiguration and security disasters. Enabling access should be easy to do to avoid mistakes at the same time a user should fully understand what are risks and how to mitigate them.

For example, opening of SSH port for WAN should be done at once click. But we should ask for a confirmation and try to force security enhancements:

• Change port or even start a separate Dropbear instance with root login disabled
• Use a pubkey auth and show an instruction how to generate a key
• (Maybe) install banip

The firewall rule to allow the SSH access from WAN must be already preinstalled but disabled by default. This will also mitigate the mistakes of manual adding.

When allowing access to LUCI we should require HTTPS and propose to configure ACME and DDNS. For the Self-hosting needs we'll need for some reverse proxy or use a separate port.

Many things to unpack here, but for now my proposition is to enhance documentation first, then add UCI configs disabled by default and then try to implement UI.

We already have a page on a Wiki Accessing LuCI web interface securely which is mainly about opposite. I added a new section to it about how to open access, that should be a proper place given that same options are changed. Please extend it from your experience.

The task is kind of epic, and I'll try to add progress in the comments. Please let me know your thoughts and if you can contribute.

[jow-]

LuCI can easily generate entire rules as needed, there's no need for preconfigured one.

[stokito]

Sure, it was easier to implement. Still, it would be good to have an example of the rules in config to help those who don't use the Luci. At the same time, why keep it commented if it can be just disabled? The same rule will be seen in Luci, which wasn't possible before because the Luci don't show commented configs. The comments may be also lost after UCI call.

Having a commented rule, we can just enable it by the uci set firewall.wan_https_allow.enabled=1. This will significantly simplify scripting and instructions. Additionally, now some other services or configurations wizard scripts can use it, not only Luci itself.

So the Luci can add the whole rule, but why do that if we know that by default we already have it? Someone can delete the rule, but if they are smart enough to do that, they can re-create it.

Cons that I see are:

1. Implicit dependency between Luci and configs. A user may remove or change that rule without knowing of side effects.
2. This works only for default 22 port. If we add a second Dropbear instance on 2222 port then we can't reuse the rule.
3. If a user decides to change the main Dropbear instance port to 2222 then the rule needs to be changed too.

I expect that for 99% of users this will work as it is.

Anyway, it's not a problem to add full train of uci set commands to Luci, I just wanted to make PoC as simple as possible.

[jow-]

Over the years I came to the conclusion that it is futile trying to provide higher level configurations in the ui while also playing nice with whatever configuration happen to be present in the system. There is just too much variation and system level differences to cater to and you inevitably will encounter configurations that do not match the expectations.

If you want rich, simple and robust features you will have to assume a certain system state and/or forcibly (over)write configurations to reach a defined desired state. In other words, such functionality should be provided in the form of task oriented wizards which query the few actually needed variables and then render out a complete set of configs or interdependent settings to set up the desired feature/task. If you do want to provide such functionality to non-gui users as well, then split the wizard logic into a series of cli scripts which are simply called from the ui.

Assuming a hypothetical cli tool "task", you'd then have commands like task setup guest-network, task allow-wan-access ports=22,80, task isolate-ethernet port=3 ipaddr=192.168.10.5/24 vlan=6 etc.