Luci not reachable when setting uhttpd to only listen on one IP address

[psherman]

@flygarn12 is correct that a dumb AP with multiple VLANs/SSIDs should generally only have a single network set as static/DHCP, and the others should be set to unmanaged (proto none). It is also correct that the interface that is managed should be associated with the trusted/management network.

Now, it is certainly possible to have multiple interfaces that are managed (i.e. static IP or DHCP client addresses), but if your goal is (as stated earlier):

@johanneskastl

This is just minimizing the attack surface. All zones that contain potentially bad devices have Input=reject

then the absolute best way to achieve the goal is to make sure that only address that exists on the OpenWrt dumb AP is associated with the trusted/management network. That address, in turn, becomes the only address that OpenWrt will be listening on, and your router/firewall can then be used to block inter-VLAN routing such that the dumb AP is not accessible from the untrusted networks. There is no reason to have any of the other network interfaces "managed" unless the OpenWrt device needs to participate on those networks.

EDIT: To clarify, when setup with only a single network using a 'managed' interface, the uhttpd config can be set to listen on 0.0.0.0 and there will be no race conditions and a reduced attack surface because this binds to all managed interfaces (and the unmanaged ones are entirely ignored because OpenWrt does not have an address on those networks).

I also think that if you have input=reject on the zones that contain your untrusted networks, the issue is more than likely stemming from your upstream router/firewall configuration allowing inter-VLAN routing.

[johanneskastl]

Guys, thanks for your help.

I agree that a dumb ap should only have one managed interface. But this is not a technical requirement, but best practice. This has nothing to do with different interfaces having the same MAC address.

However, I just changed the router to only have one managed interface, and reset the starting order back to the defaults (renamed the link to /etc/init.d/S50uhttpd).
And I still get the same error.

I am pretty sure that I can just use 0.0.0.0 for uhttpd and it will work fine, which would not be a step backwards in security terms, as there is only one interface reachable now anyway.

So this seems like a general problem that just does not surface that often (who hardens their routers or APs? )

As for the firewall, I mixed things up in my OP, this is the dumbap that does not have firewall or dhcpd running...

Kind Regards,
Johannes

[psherman]

@johanneskastl

I am pretty sure that I can just use 0.0.0.0 for uhttpd and it will work fine, which would not be a step backwards in security terms, as there is only one interface reachable now anyway.

uhttpd listening on 0.0.0.0 is also not a security issue even if multiple networks exist as managed interfaces on your router, provided that your untrusted networks are associated with a firewall zone that has input=reject, and that any upstream router does not allow inter-VLAN routing from those untrusted networks.

[flygarn12]

@johanneskastl

So this seems like a general problem that just does not surface that often (who hardens their routers or APs? )

Pretty many I would guess.

If the AP doesn’t work with my suggestion above, then I wonder? How did it work with the TP-Link original firmware in your network because my suggestion result in the same functional result as TP-Link original settings and functions for that AP?