What's new

Default iptables rules using -i br0

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Denna

Senior Member
I'm trying to understand what the default iptables rules do.

The following is the result of "brctl show".
Code:
bridge name     bridge id               STP enabled     interfaces
br0             8000.3497f6201ba8       yes             vlan1
                                                        eth1

The following are some of the default active rules built into the firmware referencing the br0 interface.
Code:
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A FORWARD ! -i br0 -o eth0 -j DROP
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -i br0 -j ACCEPT

When the "br0" interface is used, is that the same as creating multiple rules with each referencing the bridged interfaces (vlan1 and eth1) ?

Are these correct ?

First rule - Allow any traffic destined for the router via the vlan1 and eth1 interfaces with a NEW state.

Second rule - Drop any outgoing traffic going through the router that is not from the vlan1 and eth1 interfaces.

Third rule - Allow any traffic between the vlan1 and eth1 interfaces.

Fourth rule - Allow any incoming traffic through the router to the vlan1 and eth1 interfaces.​
 
If you create your own rules that don't reference the br0 interface, is deleting these rules a problem ?
 
When the "br0" interface is used, is that the same as creating multiple rules with each referencing the bridged interfaces (vlan1 and eth1) ?
You cannot simply re-write the firewall rules to specify the physical interfaces instead of the bridge interface (br0). So, I think the answer to your question is, No. When a frame enters the bridge interface (br0), all information about the physical interface (eth1, eth2, wl0.1, wl1.1, etc) is lost. This is due to optimisation in the Broadcom/Asus Linux kernel. When the frame is bridged, you cannot filter on the physical interface. When the frame is not bridged, you can. Some Linux kernels enable the xt_physdev matching module for iptables, but not Broadcom/Asus.
 
@Fitz Mutch,

I've disabled Wi-Fi on the router so I don't have any rules for eth1.

The only bridge is "br0" bridging the vlan1 (LAN) and eth1 (Wi-Fi) physical interfaces.

If I'm writing iptables rules with the bro bridge existing, any reference to vlan1 should be replaced with br0 ?

If the br0 bridge is deleted, vlan1 could be referenced in iptables rules ?

Or is it that Asuswrt-Merlin doesn't allow referencing physical interfaces at all ?​
 
If I'm writing iptables rules with the br0 bridge existing, any reference to vlan1 should be replaced with br0?
Yes, I think so. The bridge interface (br0) means all LAN interfaces. Unless you've un-bridged some (vlan1) frames with ebtables -t broute, then you'd need to reference (vlan1) in addition to (br0).

If the br0 bridge is deleted, vlan1 could be referenced in iptables rules ?
The firmware uses (br0), so I don't think that would work.

Or is it that Asuswrt-Merlin doesn't allow referencing physical interfaces at all ?
Both AsusWRT and Asuswrt-Merlin firmwares use the "ebtables -t broute" command to un-bridge frames that are destined for the bridge interface (br0). This is the only time filtering on the physical interface will work with bridged frames. Once a frame is un-bridged, you may reference it by its physical interface in iptables. It's how device isolation is accomplished for the Guest Network.

Alternatively, if you don't mind breaking binary compatibility with the AsusWRT Linux kernel, you could enable the xt_physdev matching module for iptables. Apparently, someone already did it here:
https://github.com/RMerl/asuswrt-merlin/pull/910
 
Last edited:
@Fitz Mutch,

Thanks for the detailed answer.

The result of "robocfg show" is:
Code:
Switch: enabled
Port 0:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 1:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 2:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 3: 1000FD enabled stp: none vlan: 1 jumbo: off mac: 48:ca:b1:e4:52:37
Port 4: 1000FD enabled stp: none vlan: 2 jumbo: off mac: b9:18:21:36:f7:24
Port 5: 1000FD enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 7: 1000FD enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 8: 1000FD enabled stp: none vlan: 2 jumbo: off mac: 39:81:d0:01:7e:b2
VLANs: BCM5301x enabled mac_check mac_hash
   1: vlan1: 0 1 2 3 5 7 8t
   2: vlan2: 4 8u

If "vlan1" is associated with the non-WAN Ethernet ports, what is "eth1" associated with ?

 
If "vlan1" is associated with the non-WAN Ethernet ports, what is "eth1" associated with ?

eth0 is the WAN interface
eth1 is the 2.4GHz primary Wi-Fi interface
eth2 is the 5GHz primary Wi-Fi interface
vlan1 is all wired LAN ports interface
wl0.1 is the 2.4GHz guest #1 Wi-Fi interface
wl1.1 is the 5GHz guest #1 Wi-Fi interface
wl0.2 is the 2.4GHz guest #2 Wi-Fi interface
wl1.2 is the 5GHz guest #2 Wi-Fi interface
wl0.3 is the 2.4GHz guest #3 Wi-Fi interface
wl1.3 is the 5GHz guest #3 Wi-Fi interface
br0 is the LAN (all interfaces except eth0)
 
@Fitz Mutch,

Thanks for the detailed response.

Are these interfaces documented like that in the firmware source code ?

I don't use Wi-Fi and have disabled the 2.4 and 5 GHz radios on the router. That said, I'd prefer to not have "eth1" associated with the "br0" bridge. If Wi-Fi was not going to be used, is this the correct way to remove "eth1" from the bridge ?
Code:
brctl delif br0 eth1

Is this a command that has to be run from the /jffs/scripts/init-start script ?​
 
Are these interfaces documented like that in the firmware source code ?

The majority of the questions you ask can be answered by looking at the source code.
 

Similar threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top