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.
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.
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?
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
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?
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...
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).