How to share the same subnet across two bridge interfaces?

Hello all. In my current setup I have two bridge interfaces (say br-1 and br-2), each of them having their own wifi and their own VLAN. Up until now they also have their own subnet (192.168.1.0/24 and 192.168.2.0/24) but now I want to join them in a single subnet so that a broadcast packet emitted from a PC connected through br-1 can be reached by another PC connected through br-2. I was wondering, how exactly should I setup the bridges? More specifcally:

  • Is my best bet assigning static addresses to both of them (say 192.168.1.1 to br-1 and 192.168.1.2 to br-2) or there's some other way?
  • How should I configure DHCP Server on both interfaces? My optimum would be to reserve most of the addresses to br-1 and only a few to br-2, but as far as I can see I only have a start and a limit which would be an issue because I would want a PC in br-2 to have a specific IP which is fairly low (192.168.1.36), so I guess I should put start: 36 and limit: 4 on br-2 and start: 50 and limit: 100 on br-1? Would that work? Is this the most efficient way to configure the pool?

The two bridge interfaces must be different subnets. You can’t merge them. The easiest solution is to remove one of the bridges and assign all of your physical Ethernet ports (and WiFi ssids) to the single bridge.

3 Likes

But how can I assign them two separate firewall zones then?

You can’t. If you want the networks to be joined so that they work as one so that broadcast packets can be received by the PCs, that means they exist in the same subnet and this don’t have any firewall between them.

4 Likes

Well, then I am back to square one in my journey to find a solution to my issue (explained here).

Thanks for your quick reply.

2 Likes

Thanks, will study those links as soon as I have some spare time!

Using this solution implies that both the server and the client are in the same VLAN and the same bridge, correct? I'm still not sure how to populate --physdev-in and --physdev-out though... what are lan_1 and lan_2 exactly here?

brctl show

And, sorry if I ask again but it doesn't seem to find the answer, all of this is within the same bridge, correct?

1 Like

Uhm... I just tried, but it doesn't seem to work.

root@OpenWrt:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br-lan          7fff.9cc9eb15ddce       no              wlan0
                                                        eth1.1
                                                        wlan36
                                                        wlan1

My extra was uci set firewall.lan1_lan2.extra="-m physdev --physdev-in wlan36 --physdev-out wlan0" (with wlan-36 the wifi to which the server is connected to, and wlan0 the main wifi where everyone else is attached), but traffic is still allowed.

If that helps, it seems that the rule is never matched, probably because of the previous rule in the chain that is always matched:

Chain zone_lan_forward (2 References)
Chain FORWARD, Rule #4
Chain FORWARD, Rule #5
Pkts.	Traffic	Target	Prot.	In	Out	Source	Destination	Options	Comment
261 	26.81 KB	forwarding_lan_rule	all	*	*	0.0.0.0/0	0.0.0.0/0	-	Custom lan forwarding rule chain
0 	0 B	zone_lan_dest_REJECT	all	*	*	0.0.0.0/0	0.0.0.0/0	PHYSDEV match --physdev-in wlan36 --physdev-out wlan0	Deny-wlan36-wlan0
lsmod | grep -e br_netfilter; sysctl net.bridge; iptables-save | grep -e physdev

Thanks, I'll probably have to reinstall some packages since I went back and forth with another backup.

By the way, another question: I guess that I couldn't simply create a rule with the source IP rather than targeting the physical interface. Why is that exactly? Why I do need to use physdev?

If you don't need scaling, then using IP/MAC is also fine.

No, scaling is not required, so IP (already set a static lease) can be a valid option in my case. Point is that I tried that approach as well, and it seemed to work for blocking INPUT (the router was not accessible anymore) but other clients were still accessible...

br_netfilter           24576  0
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-filter-pppoe-tagged = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0
net.bridge.bridge-nf-pass-vlan-input-dev = 0
-A zone_lan_forward -m physdev --physdev-in wlan36 --physdev-out wlan0 -m comment --comment "!fw3: Deny-wlan-36-wlan0" -j zone_lan_dest_REJECT

The bridge firewall will only work if the bridge device is literally in the path between the two devices in question such that the traffic must physically flow through this bridge in order for the two devices to communicate. If they are connected by two ports on another switch somewhere, the traffic will not pass through the bridge and therefore cannot be filtered by a firewall.

There are three broad rules that are applied at zone-level: Input, Output, and Forward. It is necessary to think about these rules from the perspective of the firewall itself, not from outside looking in.

  • Input controls the ability for a zone to connect to the router/firewall itself (i.e. administration, services locally hosted on that device, etc.)
  • Output controls the traffic flow out of the firewall towards the zone (network).
  • Forward controls the traffic flow between multiple networks that are assigned to the same zone.

You can think of the firewall and routing engines as something of a sandwich, where in this silly analogy the firewall is the bread and the routing engine is the stuff between the bread. Traffic coming from a particular source network first goes through the firewall (pre-routing), then if the traffic is accepted, it goes into the routing engine to be routed to the appropriate network, and finally passes through the firewall again (post-routing) before it egresses to the destination network (again, if allowed).

Looks like you missed this step:
https://openwrt.org/docs/guide-user/firewall/fw3_configurations/bridge#command-line_instructions

1 Like

My bad, I skipped right to last part not noticing the first.

And now I can finally say it works! Thank you so much!

Also thanks @psherman for taking the time explaining mw those concepts. Yay, mission accomplished!

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.