Is it possible to have applied separate routing rules based on firewall zones, in other words, to define routing rules that are applied statefully based on the source interface of incoming traffic?
Presently, a switch running OpenWrt has been configured with two bridged interfaces.
One bridged interface, encompassing a single Ethernet port and a dedicated SSID, is intended strictly for administration, in a fallback scenario, to access the administrative web portal of OpenWrt. For the most reliable and compliant operation within such a scenario, the address assigned is 192.168.1.1/16.
However, the other bridged interface, which includes the remaining interfaces, including Ethernet ports and a different SSID, connects to a router, in turn connected to an entirely separate subnet, though also designated as 192.168/16. Devices on the subnet should be reachable within normal operation of the switch, that is, not involving the dedicated administrative Ethernet port and SSID. In particular, for connections on the administrative bridged interface, the web portal should be served to clients by address 192.168.1.1. For connections on the other bridged interface, a static routing rule should be observed, directing traffic to an appropriate gateway for 192.168/16.
I have attempted creating a separate firewall zone for administrative access, configured to reject forwarded traffic.
However, I have not yet reached an overall configuration in which routing rules are applied fully separate depending on which interface traffic is incoming.
The overlapping subnets will cause problems and constitute an invalid configuration. This is true for all routers, although you may not experience issues on a switch if it holds only a single address.
Why do you have 2 overlapping subnets in the first place, and why are you using /16 subnet sizes??
The adjacent 192.168/16 network cannot be reconfigured.
A different address could be assigned for administration of the device, but the objective is to ensure a reliable fallback that would remain fully independent of other constraints.
That can only be guaranteed if the device does not hold an address on the other subnet. Or if the two subnets are non-overlapping.
Besides, it is bad practice to knowingly use overlapping subnets in this way, and it is illogical to use /16 subnets in the vast majority of cases. I have no idea why the upstream network is using this large of a subnet, but I would highly recommend that you use. 10. address with a /24.
All interfaces on a routing device must be on non-overlapping subnets.
If a 10./24 is in use, there are many other 10. addresses you can use. It is after all a /8 space. And failing that, you can use the 172.16.0.0/12 space.
If the interface holds an address and that interface is then associated with a firewall rule that allows or prohibits input, that will dictate the ability for hosts on that network to reach the device.
But, maybe the switch should simply not have an address on the interface that is associated with the upstream network. That interface can be unmanaged and then you don’t need to worry about it being accessible.
Firewall rules were considered only in the hope that particular routing rules could be limited as applying exclusively within particular firewall zones.
Whereas a routing table in itself is static, a firewall is stateful. Firewall rules are processed based on source interface and directional distinction, not just destination address.
The device is assigned addresses strictly for administrative access, which must remain possible even during normal operation.
The switch shouldn't be doing any routing whatsoever since you have an upstream network already defined. The switch should be transparent to all of the devices that connect to the switch should not know or care that they are connected to it... for all they know, they could be directly connected to the upstream router. This is how switches (and APs) normally work.
There are two ways to handle the administration of the switch/AP itself...
Allow the upstream network to have access to the switch/AP, thus allowing any host on the upstream network to make a connection, login, and then administer the device.
Configure a secondary interface specifically for the administrative functions. This would be a distinct and non-overlapping subnet to which you'd connect a device (via Ethernet and/or WiFi) and that would have access to administer the switch/AP.
Usually, the administrative network interface in option 2 would only have access to the device being managed, but it is possible to add routing so that it can be used for general internet access and the like (performance depends on the actual hardware involved here).
You can allow administrative access via options 1 and/or 2. It is possible to restrict the administrative access further if you want by allowing only specific hosts to access the administrative services.
Yes, I understand. The upstream network has access to the device under normal conditions, through regular routing
I strongly favor, however, maintaining the device configured as the first physical interface assigned 192.168.1.1. As such, anyone may resolve fallback administrative access to the device, without knowledge or assumptions about its current state or previous provisioning.
It's not routing (L3). It's accessible on the network at L2 (switching).
Why?? There is nothing magical about 192.168.1.1 except that it is the default address that OpenWrt (and so many other) devices use. There is no inherent need to keep that address.... all you need to know is the alternate address. There are lots of ways to achieve this.
Who else needs access to the device? Is it just you? A limited/specific group of users? Or literally anyone?
Let's talk about why you are setting up an alternate administrative interface...
You keep talking about:
so, with that in mind, what are the circumstances under which this device needs to be accessed that are "not normal conditions"?
In addition, you described the fact that the upstream 192.168.0.0/16 network is upstream and you cannot change that. However, are you able to assign a static IP address to your switch? If so, the alternate address is actually not required.
I am referring to a network, upstream, on the other side of a router connected to the device.
Devices on the other network should have a path to the web portal on the device, for which of course is required the intermediary router, adjacent to the device running OpenWrt and operating as an L2 switch.
The address is the one everyone knows to expect, and everyone knows that everyone knows, to expect.
There is nothing magical about any protocol or semantics, more than the accurate expectation of consistent invocation and mutual comprehension.
Anyone should have a direct course to query or to provision the device, without having any specific or recent knowledge of its history or status.
Of course, the gamut is essentially boundless, of possible changes or failures, even ones directly consequent of maintenance and provisioning, that could render an existing site configuration at diminished functioning.
The interfaces providing normal switching (which include all but one) have been assigned a static address, on the downstream subnet being switched, as a bridged interface.
The address is needed only for the embedded web server (Luca).
How about a network topology diagram?? That will make this much more clear.
Currently, you've mentioned a 192.168.0.0/16 network to which this OpenWrt device is connected. Any hosts on this network will reach the OpenWrt switch/AP via L2 switching (no router involved).
From where else are devices connecting?
What other network? (Again, a topology diagram will really help).
eh.... maybe, but not really. And it depends who "everyone" is here.
For example, TP-Link's default address is 192.168.0.1 for many of their devices.
And, since the person connecting to this device (in the non-normal condition) will likely be in physical proximity (so they can connect to the alternate ethernet port and/or wifi), you can label the device to indicate the IP address of the backup interface. Also, depending on who this is targeting, you can also document it in a common location so that any other admins/techs/whoever can look that information up.
Or... if you have a dedicated network for this purpose that includes a DHCP server, any administrator worth their salt will be able to look at the assigned address/subnet and gateway address and understand where they need to go to administer the device.
Define anyone? Are we talking about a household of family members/friends/roommates? A small business? A large public space of some sort?
What about the administrative password?
It doesn't sound like you have specific failure modes in mind. There are a million ways things can go wrong on a network... most of them have zero relevance here. Many of them may be bigger problems that don't involve the switch at all, obviating the need for someone to log into this device in the first place.
If you want to have a real contingency plan that is logical and robust, outline the specific failure modes you are concerned about and let's build around that. Trying to plan for every conceivable issue means that you must create a list or model of those issues. And it further requires that you consider how this device would be impacted and why someone might need to access it.
For example, if the upstream router goes down and the internet stops working, logging into the switch isn't going to help with that.
All that said, the solution is extremely simple here...
If the primary interface has a static IP address, it will always be accessible at that address. The admin might need to enter a static IP into their computer to access it, but it will be reachable as long as the L2 connections are physically functional (worst case, plug into the switch itself on one of the standard ports, possibly unplug the uplink).
Create a secondary management network with a different subnet and a DHCP server enabled. This gives all the necessary info (except the password) to anyone who is qualified to administer the device.
So the device already has a static IP? Problem solved... it will always work (unless you have bigger issues).
And what do you mean by downstream networks here... you've described this device as a switch and AP. While the are downstream ports and STA devices connecting to the AP, they are all on the same network.
Let's see a diagram. I think that will clarify the setup.