Is it possible for a device plugged into a port, untagged traffic going to VID 20, to request a DHCP address from a different subnet served by the same OpenWrt router/DHCP-server?
Given that accepting input from the zone lets me ping the router at both 192.168.1.1 as well as 192.168.20.1 (the guest network subnet), I don't see why this wouldn't be the case. (LUCI lets me add a destination IP to the rule (eg. 192.168.20.1), but that doesn't really make sense here as a new device wouldn't know where to send the initial request to).
Furthermore, would this allow the rogue device to contact devices on a different VLAN, or would the VLAN-interface-zone -coupling restrict it to only be able to abuse IP-based firewall rules?
You almost certainly have a firewall configuration that will accept input for that zone. The reason that 192.168.1.1 will return pings is because it is actually the same device as 192.168.20.1, and it recognizes that before it attempts to do any firewall/routing processes.
No, not unless you have your firewal configured (or mis-configured, depending on your perspective) to allow inter-VLAN routing.
We'd have to see your configuration to be able to further advise.
I need to check whether a rule allowing pings from guest zone to 192.168.20.1 only will also allow pings to 192.168.1.1, but "it recognizes that before it attempts to do any firewall/routing processes" sounds a tad bit exploitable - at least you can find out which subnets the router belongs to. Thanks for the answer.
This is sometimes called loose address mode or similar. In the 90ies there were huuuuuge debates between Linux and bsd users argumenting that the other side is wrong about their views.
Personally I think the Linux default is good as it identifies a host and not only an individual network interface. But you are able to tighten the Linux host to only respond to addresses on an interface and not to every address the host holds...
Let's take a look at your configuration.... I'd like to see these and then the results of your 'fingerprinting' when connecting from a restricted VLAN.
Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
I'd like to look further into this as well, but I don't have the time to refresh myself on port scanning right now, sorry. Besides,
You almost certainly have a firewall configuration that will accept input for that zone. The reason that 192.168.1.1 will return pings is because it is actually the same device as 192.168.20.1, and it recognizes that before it attempts to do any firewall/routing processes.
If this is true, my specific configuration shouldn't matter - as long as the router accepts any input traffic sent to an IP outside the VLAN - DHCP requests included - it reveals that the router has that IP. How many and which subnet IPs the router has are bits of information that differ between networks, and can be combined with other available metadata (MAC, other clients, pings to outside world) to uniquely identify the network. This is called 'fingerprinting'.
Sorry if this is OPSECsplaining, I just don't see how my config is relevant here - you said that this happens before "any firewall/routing processes".
if you have the router accepting input on the network/zone in question, a user would be able to probe and access services on the router itself, but no further unless inter-vlan routing is explicitly allowed.
if you have the router set to reject/drop input on the given zone, probing would return nothing except for services/ports explicitly accepted (typically DHCP and DNS).
In both cases, unless inter-vlan routing is allowed, you will not be able to probe anything else on any other networks. And, you will not be able to obtain an address via DHCP from another subnet, anyway. Even if you set your address to a static IP in one of the other subnets, you will not be able to VLAN-hop if the port is set to a different VLAN.
If you can show that OpenWrt allows traffic that should not be permitted, I'm sure it would be of great interest. Absent any evidence to the contrary, I am quite certain that my above statements are correct (assuming proper configurations).
Yes, indeed, the user can only probe the DHCP server of the router here. It's enough for fingerprinting, but afaia not anything else. While, as I mentioned in the first post, LUCI does allow you to specify a destination IP in the DHCP rule, this doesn't actually work as clients simply fail to contact the router. There are alternative ways to limit the fingerprinting, but those sysctls options seem to be the least disruptive, allowing normal/non-paranoid plug-n-play use.
Please keep in mind that Vlan,DHCP, IP ,... Are only slightly related to each other.
On a Vlan you can have more then one layer3 network. You could also serve these layer3 networks via DHCP. And DHCP gets requested via broadcast on ipv4.
And I would argue that there is no opsec what so ever in knowing about IP addresses of a router.
If you for some reason want or need to restrict access on addresses you use access control list and Firewall rules.
But still stuff like broadcast and icmp traffic needs to hit the router otherwise stuff gets broken. But IP addresses are in no sense private or secure information.
