LUCI interfaces / Protecting local services efficiently on a "managed switch / AP"

Situation: A device is running 18.06.2 or a later snapshot. It is configured as an access point. The starting point for the configuration was Dumb AP / Access Point Only. From there, several VLANs were set up. It's tagging data for the trunk based on their source (SSIDs, LAN ports), and distibutes data accordingly in the opposite direction.

As per "Dumb AP / Access Point Only", the firewall is disabled. No services running (IP ports open) except for LUCI. Depending on the VLAN, traffic is trusted or not. In trusted VLANs, the device has an IP address, so it is visible and can be configured. Not so in untrusted VLANs, which provides a bit of protection.

Intention: When I would like to add server functionality to the devices (e.g. printer / file sharing), the situation changes. Providing this for untrusted VLANs requires the device to have an IP address in that untrusted VLAN. But I would like to avoid having to enable the firewall. (E.g. CUPS has an "allow" directive in its configuration.)

Questions:

  • Am I right in assuming that all local services are bound to the CPU port of the switch, and there's no way to change that?
  • Am I wrong in trying to avoid the firewall because it requires fewer resources than I think?
  • Does LUCI have a config option to accept incoming login attempts only from certain address ranges? Did not find any documentation on that so far.
  • Yes
  • Yes
  • No (use firewall)

As soon as you introduce L3 or higher, it isn’t a “dumb AP” any more and you have to deal with interfaces accepting and/or routing packets.

3 Likes

Thank you! It should indeed be emphasised that this is not a "dumb" device anymore, even in its current configuration.

Not even sure what being a "dumb" device means, ad you set up trunks.

If you are trunking and have VLANs, doesn't the other device have a firewall?

You would allow it there.

I believe @jeff took the word "dumb" from the headline of the "Dumb AP / Access Point only" project page which I referred to and which I took as a starting point. I myself see my result more as a "managed switch / AP" as mentioned in the thread name.

Either way, yes, the "other" device (a central router, dealing with the APs, also for handoff) does have a firewall. But it sees only cross-trunk traffic. That includes traffic between devices in the same VLAN but on different trunks. But not local traffic within the same VLAN "behind" the trunk. That would be handled by "the trunk's local switch" if possible, and it also includes anything the switch offers locally (as long as it's in the same VLAN). So the central router's firewall would not be able to limit access to the services of a trunk's switch, such as LUCI in this case. No?

You had to have defined the VLANs and firewall somewhere. There's some device with a gateway and hence a firewall.

Wonderful! That's where you permit traffic to the printer.

Are you saying:

When I enable another local service besides LUCI on the OpenWRT device, then that is provided in another VLAN where then the OpenWRT device has an IP address. And access to that service (VLAN and port) is controlled by the firewall in the central router.

However: Enabling that additional service will lead to that service also being available in all VLANs where the OpenWRT device has an IP address, and that is not necessarily intended. So additionally, I would have to restrict that service locally on the OpenWRT device.

  • Why do you keep mentioning LuCI and OpenWrt when you continually state you don't want to configure access to the printer there?
  • Are planning to run CUPS and other services on the OpenWrt or something???
  • If that's the case, then obviously you'd have to either config the service to:
    • properly listen to the correct IP;
    • or correct interface

If the server is on another device, this would work by:

  • making the config change there;
  • or (if on the OpenWrt itself) enabling the OpenWrt firewall; and making the change there

Simple.

Answers to your questions are already in my text. You've increased your distance to the heart of my question somewhat. Nevertheless, I appreciate your replies.

1 Like

It's not clear if CUPS will be on a device with access to multiple LANs (you imply it once, though; and when you mentioned CUPS, I assumed), if that's definite, you have to firewall input at the OpenWrt (or ensure the software is properly listening).

Since I won't guess, I hope others will assist until you make it clear in text.

Also, disable routing on the OpenWrt, to ensure you don't get any other odd issues.