ebtables, ARP, and wirleess guest network

[macaroon]

I'm running Asuswrt-Merlin 380.57 and I want to allow users in the wireless guest network (wl0.1), which is not allowed access to the intranet, to access the DNS server on the intranet. It appears that segregation of the wireless guest network is done by ebtables rules:

Bridge chain: FORWARD, entries: 2, policy: ACCEPT
-i wl0.1 -j DROP
-o wl0.1 -j DROP

Therefore, I tried adding ebtables ALLOW rules at the top of the FORWARD chain of the filter table to allow traffic to and from the appropriate protocol/IP/port since it was clear by looking at the counts that the above rules were doing the blocking. (Note: there is also an entry in the BROUTING chain of the broute table but according to the counts, the traffic isn't making it to that table.) I then realized that I needed to allow ARP packets accross the bridge for the segregated interfaces (I'm used to iptables, not ebtables). However, once I did that (before I added the custom rules described above for the DNS traffic), it appears that all traffic to/from the wireless guest network was allowed on the intranet. I don't understand why this is happening. The DROP rules from above are still in place it's just that I added two rules above them to allow ARP to and from wl0.1. Shouldn't non-ARP traffic from wl0.1 to/from the intranet still be blocked?

Any insight is appreciated.

Thanks!

 

[Martineau]

I'm running Asuswrt-Merlin 380.57 and I want to allow users in the wireless guest network (wl0.1), which is not allowed access to the intranet, to access the DNS server on the intranet. It appears that segregation of the wireless guest network is done by ebtables rules:

Bridge chain: FORWARD, entries: 2, policy: ACCEPT
-i wl0.1 -j DROP
-o wl0.1 -j DROP

Therefore, I tried adding ebtables ALLOW rules at the top of the FORWARD chain of the filter table to allow traffic to and from the appropriate protocol/IP/port since it was clear by looking at the counts that the above rules were doing the blocking. (Note: there is also an entry in the BROUTING chain of the broute table but according to the counts, the traffic isn't making it to that table.) I then realized that I needed to allow ARP packets accross the bridge for the segregated interfaces (I'm used to iptables, not ebtables). However, once I did that (before I added the custom rules described above for the DNS traffic), it appears that all traffic to/from the wireless guest network was allowed on the intranet. I don't understand why this is happening. The DROP rules from above are still in place it's just that I added two rules above them to allow ARP to and from wl0.1. Shouldn't non-ARP traffic from wl0.1 to/from the intranet still be blocked?

Any insight is appreciated.

Thanks!

This post should help....

http://www.snbforums.com/threads/limit-the-guest-network-ports-and-speed.13955/#post-92668

..and unless you also want to restrict which traffic is allowed on the Guest1 2.4Ghz SSID then you probably won't need this rule:

/usr/sbin/iptables -I FORWARD -i wl0.1 -p tcp -m multiport --dports http,https,imap,smtp,pop3,sftp,ftp,imaps -j ACCEPT

and change the final rule to match your LAN.

 

[ASAT]

there is also an entry in the BROUTING chain of the broute table but according to the counts, the traffic isn't making it to that table.

The ebtables BROUTING chain is processed very early in the packet flow. And it's what moves certain packets from the physical interface (wl0.1) to the bridge interface (br0), unless you tell it to do something different.

These two rules (from Martineau's link) cause the IPv4 and ARP packets to stay on the physical interface (wl0.1). They will not be bridged (br0). The target DROP, when used within ebtables BROUTING, means don't bridge (wl0.1) to (br0), keep the packets on the physical interface (wl0.1), and allow these packets to be routed. Nothing gets dropped like with other chains.

/usr/sbin/ebtables -t broute -I BROUTING -p ipv4 -i wl0.1 -j DROP
/usr/sbin/ebtables -t broute -I BROUTING -p arp -i wl0.1 -j DROP

Packet flow in Netfilter and General Networking
https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg

 

[macaroon]

The target DROP, when used within ebtables BROUTING, means don't bridge (wl0.1) to (br0), keep the packets on the physical interface (wl0.1), and allow these packets to be routed. Nothing gets dropped like with other chains.

Ah, that I did not realize and it helps explain a lot. Thank you. Basically use ebtables to kick the wl0.1 traffic up to iptables and then deal with it there. Couldn't you just remove wl0.1 from the bridge (br0)?

 

[ASAT]

Couldn't you just remove wl0.1 from the bridge (br0)?

Before you try to remove (wl0.1) from (br0), make a short list of everything that will break:

• DHCP for the LAN serves (br0). Need to configure dnsmasq.conf to fix it.
  
• Some firewall rules refer to (br0). Must add additional iptables rules to fix it.
  
• WPA2 wi-fi might not work as expected. Must re-configure some nvram variables and restart eapd.

I believe it is possible. However, in the meantime, you can jump straight to the front of the line, by cutting in front of half-a-dozen people, with one simple trick.

The xt_physdev matching module for iptables lets you filter on the physical interface even when it's bridged. We can enable this module by enabling the CONFIG_BRIDGE_NETFILTER kernel option. However, you must re-compile the Asuswrt-Merlin firmware using your desktop computer. Now the following iptables rule will work, for example:

/usr/sbin/iptables -I FORWARD -m physdev --physdev-in wl0.1 -j DROP

~/asuswrt-merlin-380.57-arm-bridgenf.patch

diff -u -r -B -X ./excludes.txt ./asuswrt-merlin-380.57-original/release/src/router/rc/wan.c ./asuswrt-merlin-380.57/release/src/router/rc/wan.c
--- ./asuswrt-merlin-380.57-original/release/src/router/rc/wan.c    2015-12-24 16:18:19.000000000 -0500
+++ ./asuswrt-merlin-380.57/release/src/router/rc/wan.c    2016-01-13 18:19:02.080739575 -0500
@@ -3094,8 +3094,16 @@
#endif
#if LINUX_KERNEL_VERSION >= KERNEL_VERSION(2,6,36)
-    f_write_string("/proc/sys/net/bridge/bridge-nf-call-iptables", "0", 0, 0);
-    f_write_string("/proc/sys/net/bridge/bridge-nf-call-ip6tables", "0", 0, 0);
+    #ifdef RTCONFIG_BCMARM
+        // for ARM platform, we have enabled BRIDGE_NETFILTER and the default behaviour
+        // is to pass bridged IPv4 & IPv6 traffic to iptables' chains
+        f_write_string("/proc/sys/net/bridge/bridge-nf-call-iptables", "1", 0, 0);
+        f_write_string("/proc/sys/net/bridge/bridge-nf-call-ip6tables", "1", 0, 0);
+    #else
+        // for MIPS platform, the BRIDGE_NETFILTER feature is not yet enabled
+        f_write_string("/proc/sys/net/bridge/bridge-nf-call-iptables", "0", 0, 0);
+        f_write_string("/proc/sys/net/bridge/bridge-nf-call-ip6tables", "0", 0, 0);
+    #endif
#endif
     /* Report stats */
diff -u -r -B -X ./excludes.txt ./asuswrt-merlin-380.57-original/release/src-rt-6.x.4708/linux/linux-2.6.36/config_base.6a ./asuswrt-merlin-380.57/release/src-rt-6.x.4708/linux/linux-2.6.36/config_base.6a
--- ./asuswrt-merlin-380.57-original/release/src-rt-6.x.4708/linux/linux-2.6.36/config_base.6a    2015-12-24 16:18:19.000000000 -0500
+++ ./asuswrt-merlin-380.57/release/src-rt-6.x.4708/linux/linux-2.6.36/config_base.6a    2016-01-13 18:16:28.112733329 -0500
@@ -476,7 +476,7 @@
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
-# CONFIG_BRIDGE_NETFILTER is not set
+CONFIG_BRIDGE_NETFILTER=y
#
# Core Netfilter Configuration

Recompile the Asuswrt-Merlin source code

cd ~/asuswrt-merlin
patch -p2 -i ../asuswrt-merlin-380.57-arm-bridgenf.patch
cd ~/asuswrt-merlin/release/src-rt-6.x.4708
make clean
rm .config
make rt-ac68u

 

[macaroon]

Before you try to remove (wl0.1) from (br0), make a short list of everything that will break:

• DHCP for the LAN serves (br0). Need to configure dnsmasq.conf to fix it.
  
• Some firewall rules refer to (br0). Must add additional iptables rules to fix it.
  
• WPA2 wi-fi might not work as expected. Must re-configure some nvram variables and restart eapd.

I believe it is possible. However, in the meantime, you can jump straight to the front of the line, by cutting in front of half-a-dozen people, with one simple trick.

The xt_physdev matching module for iptables lets you filter on the physical interface even when it's bridged. We can enable this module by enabling the CONFIG_BRIDGE_NETFILTER kernel option. However, you must re-compile the Asuswrt-Merlin firmware using your desktop computer. Now the following iptables rule will work, for example:

/usr/sbin/iptables -I FORWARD -m physdev --physdev-in wl0.1 -j DROP

Yeah, the only thing I didn't think about was the WPA2 possibly breaking. Enabling xt_physdev module may come in handy down the road with some things I want to do with some of the other physical ports too. Thanks for the patch and pointers.

But functionally, what is the difference between:

/usr/sbin/iptables -I FORWARD -m physdev --physdev-in wl0.1 -j DROP

and

/usr/sbin/iptables -I FORWARD -i wl0.1 -j DROP

Thanks again.

 

[ASAT]

what is the difference?

Your 2nd rule would never be matched because the iptables sees the packet as having a source interface (br0). And this sets you back, to the original question of what is the 'officially endorsed' technique to un-bridge a physical interface (wl0.1) from a bridge interface (br0).