RFC: "Guest Wi-Fi using LuCI" rewrite

Hi, newb here. I recently struggled with setting up guest wifi on 21.02. First, the cli/script failed. Then I failed at following the luci steps, producing a different error which led me to discover a fix for the script. Not sure if that's correct, sufficient (haven't tested IPv6), or even required (eg. without AP isolation), but unlike the previous version of the script, I can confirm that it works.

I'd quick-fix the LuCI tutorial too, but I'm having a hard time finding the appropriate place for my edit. Take a look at the following, which is a single paragraph between two screenshots:

You will need to configure your interface before it is useful. Choose Edit, pick the protocol Static address, and fill out your chosen IPv4 address. We chose 192.168.3.1 here, but you may have different preferences. However, avoid using 192.168.1.1 or 10.0.0.1 as they may already be in use and prevent your guests from acquiring IP-addresses. Remember to set the netmask. If you are using a newer version of the web interface, the netmask must be entered together with the IPv4 address, for example 192.168.3.1/24. You will also need to enable DHCP, we chose to go with the default options here except for the Leasetime which is only one hour, suitable for environments where a large number of guests connect and leave through a day.

Besides not being "easy to read and easy to edit", the whole wiki page goes against mantra #4 by neither applying to the current stable release nor specifying which version the (additional) instructions are valid for.

Since the wiki doesn't have a pull request system, I'm hereby formally asking permission for a full rewrite. My main concern lies with setting the IPv4-Netmask under DHCP Server > Advanced Settings (dhcp.guest.netmask), which is separate from the only netmask mentioned in the current article (network.guest.netmask). Can someone more knowledgeable please verify that this is indeed a correct, required step? Thanks!

2 Likes

You could copy the respective page to the inbox (just add inbox: in front of the path), do your edits, and then ask for comments / verification.

2 Likes

Thank you, I was not aware of the inbox. Could you add a mention of it to the contribution guide? I lack the permissions to edit it.

I'll start drafting the page, but if anyone wants to confirm the step mentioned in the OP in the meantime, I'm all ears.

Done, inbox + playground added.

1 Like

How about description regarding the relevant tick box to isolate guest WiFi clients across multiple AP's using bridge filtering in context of nftables?

I can say with confidence that I know some of those words. Care to elaborate?

I'm assuming you don't mean the simple AP isolation (preventing client-to-client connections) attainable via ticking the "Isolate clients" box, which imo should be covered.

So whenever someone sets up a Guest-Wifi network it is desirable to also set up isolation between the clients to stop clients from communicating. The guest isolation feature for a single access point is nice, but in the case of multiple access points it is still desirable to maintain isolation between guests. That requires some behind the scenes bridge filtering. With etables it was a simple command:

ebtables -A FORWARD --logical-in br-guest -j DROP

but things are a bit different now with the new nftables firewall.

In any case I am assuming such client isolation is achievable in LuCi using an appropriate tick box, since this is such an obvious feature for users to want to implement. And some kind of documentation about this would be helpful.

1 Like

Thanks! Roaming-enabled multi-AP guest networks might be outside of the scope of the initial rewrite for the time being, but others are welcome to add a section on them.

1 Like

Another vote for update on the instructions with LuCi. :slight_smile:

I did something incorrectly, with plenty of guesswork, since access to OpenWrt router is still possible from a guest WiFi android phone.

EDIT: Even tried some YouTube tutorials but those did not work out either since the LuCi/features/options? changed in 21 stable releases. :frowning:

It is not required to specify any netmask there, it is inherited from the interface configuration by default. Only in some very specific cases it is required to override the DHCP pool netmask.

1 Like

Thanks for the reply @jow. Could you give examples of some of those specific cases? Anecdotally, one of my devices seemed unable to obtain an IP address after connecting to the network without it, but I'd have to "replicate the experiment" in order to call it a data point.

Thanks, I'll be sure to get to it as soon as I'm able - good to know it's not just me :slight_smile:
For the time being, the cli/script should work on the current stable series - did for me at least. Backup your existing configuration via LuCi first, so you can restore it if it doesn't.

Thank-you, will take a look at it.
Not familiar with CLI so will take time to peruse it.