bridge and NAT - ebtables support

[menulis]

Hi all,

I would like to ask if there are any plans to make the firmware together with ebtables support for the kernel?

I have the following situation: I want all the LAN ports and a WAN port to be in a bridge thus I'm able to communicate with the LAN connected to the WAN port. What is more, I need to NAT 192.168.1.x private addresses to an external IP which then is also routed through the same LAN.

I tried to play with proxy arp on br0 and eth1, but I realized that this way I could not receive any broadcast packets from LAN (that which is connected to WAN port), so IMHO ebtables (a kernel patch actually) would be the only way to do the NAT inside the bridge.

Any thoughts are appreciated :)

Dziugas

[Oleg]

You do not need bridging/ebtables if you want to use NAT. You just need to yet another MASQUERADE rule to the iptables or setup routing between to LANs.

[menulis]

Hi, Oleg,

thanks for the answer. The problem is that if I assign eth1 interface to be in br0 logical bridge, all the interfaces (eth0, eth1, eth2) are in one brigde, and it's obvious that one interface can't belong to more than one brigde. That's why there is no routing between LANs, because basicly there is one LAN and NAT should be done according to the source address (-t nat -I POSTROUTING -s 192.168.1.x -d 0/0 -j DNAT --to 1.2.3.4 or similar).

Because brige operates in the second (data) layer, it's imposible to match the packets with iptables as bridged traffic flows before any iptables rules. That is what ebtables are designed for - to be able to match (say, filter, NAT or whatever) bridged traffic.

Dziugas

[Oleg]

You do not need bridging at all. Why you're trying to use it?

[menulis]

I do NEED it, because I want to access the LAN (30+ PCs) which is connected to the router's WAN port and which by default is not assigned to the bridge! :)

[Oleg]

But why do you need a NAT in this case? :confused:

[Oleg]

Once again. You need to setup either bridge or NAT. Not both at the same time.

[menulis]

Oleg,

I know that it's quite uncommon situation, but however, I must have an external IP configured on the router and I want my "house LAN" (192.168.1.x) to be masqueraded to that IP. As I said before, I would also like to reach my "big LAN" which is connected to WAN port and which is using, say, 10.0.0.x addresses. So my "house LAN's" (those PCs which are connected to Asus router) are configured with an IP pair - 1.2.3.x and 192.168.1.x and the Asus router currently has 192.168.1.1 on br0 and an external IP on eth1. Now everything works fine except that I can't reach the "big LAN" directly, that's why I need bridge + NAT. Thus my external IP should obviously move to br0:0 as eth1 would join the bridge.

However, how complicated my situation could sound, I would like to ask once again if there are any plans to release the upcoming firmware together with ebtables-enabled kernel?

Thanks.

Dziugas

[tomilius]

This thread was created to track the implementation of "ebtables" on the WL-500g.

I'm trying to get this working--everything seems to be going (it's all compiling now). Here's what I did...

I got (from http://sourceforge.net/project/showfiles.php?group_id=39571):
ebtables-2.0.6
ebtables_kernel-2-0-003

I installed the ebtables_kernel-2-0-003 kernel patch with few problems (typical adjustments: had to rename broadcom/src/linux/linux to linux-2.4.20, had to move files put in broadcom/src/linux/linux-2.4.20-patch to linux-2.4.20, had to manually patch broadcom/src/linux/linux-2.4.20/Makefile looking at the diff file, renamed back to linux).

I put ebtables-2.0.6 in gateway, renamed to ebtables, updated Makefile (basically copied the iptables entries but eliminated all CONFIG-related stuff and the extension installation since they are built-in afaik).

Did a kernel config and set ebtables support along with all extensions.

Now we'll see how it works.

[tomilius]

OK, I accidentally didn't modify the Makefile for ebtables which is apparently a necessity...

[tomilius]

But there's more!

[admin@AsusRouter root]$ ebtables -L
The kernel doesn't support the ebtables filter table.

*ahem* This has happened before. When I first tried to get support for new iptables extensions to work, they would inexplicably not work, as though even though I THOUGHT the kernel was being recompiled (all signs indicated this), it wasn't. Hmm. Everything appears to be set up correctly, but it's not working.

[tomilius]

OK, I'm done trying to get it working since I wasted several hours there and nothing doing. Somebody else who feels like it with more experience can try it and post here! :)

[tomilius]

No I'm not. It seems to have worked now. I did all of my modifications over with 1.9.2.7-5 and made a resolution to completely recompile stuff when the kernel is changed... One of those, or both, solved it. I'll port more about it later, I'm just saying that it doesn't seem to be complaining about nonexistent tables when I run a "ebtables -L" (shows empty chains).

[tomilius]

Yeah. A lot of posts I've made, but it works. The instructions in my first post merely need to be followed. Perhaps I could make a simpler patch version later, but I doubt it.

[Oleg]

tomilius, I will review your patches. Just need to check for the ebtables+netfilter stuff which you're probably touching. Unfortunatly this could break LAN <-> WLAN communication, as firewall does not expect such packets. Have you tried opening windows share, which traverse LAN-WLAN bridge?

[tomilius]

Oh, yes. Everything works (communication between WLAN and LAN has no issue whatsoever). I suggest, of course, using the patches from here (http://nochances.net/files/wl-500g/patches/wl500g-1.9.2.7-5-enh-1.patch.bz2) in case you were going to try any of the others I've mentioned or sent you (that one is all-inclusive).

Again, I've run into no problems yet (well, at first the WAN connection was extremely slow, but this seemed to be a random heating issue or something because it's left and won't repeat itself). I'm not sure what you mean when you say "firewall does not expect such packets"--ebtables is like a lower-level iptables almost (afaik), and with no rules set the bridge should operate exactly like it would without ebtables at all.

[Oleg]

tomilius, ebtables+netfilter patches makes bridged packets visible to iptables. that's why I'm talking, that firewall does not expect this. I've ported this patch and ebtables, but then Snufkin found, that this breaks internal traffic.
Read this: http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html

and check this as well
http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png

[tomilius]

Hmm. Well, I'm looking, and from what I understand looking at the Packet Flow image, something like this would stop wireless communication with wired computers after ebtables had been applied:

iptables -I FORWARD -i eth2 -o eth0 -j DROP
iptables -I FORWARD -i eth0 -o eth2 -j DROP

Am I right? Because it doesn't.


A bridged packet never enters any network code above layer 1 (Link Layer). So, a bridged IP packet/frame will never enter the IP code.


Say br0 has ports eth0 and eth1. If iptables rules can only use br0 there's no way of knowing when a box on the eth0 side changes its source IP address to that of a box on the eth1 side, except by looking at the MAC source address (and then still...).

Sorry, it's sort of late and I'm having problems understanding exactly what the issue is, and I haven't had any :) If you could give me an example of a situation in which a problem would occur it might help, but I'll read more later.

[tomilius]

Are you talking about section 7 of the site you showed me? The default rules avoid the problem mentioned there:

Here's a possible scheme to use at bootup for the bridge/router:

iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -d 172.16.1.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -j MASQUERADE

brctl addbr br0
brctl stp br0 off
brctl addif br0 eth1
brctl addif br0 eth2

ifconfig eth1 0 0.0.0.0
ifconfig eth2 0 0.0.0.0
ifconfig br0 172.16.1.1 netmask 255.255.255.0 up

echo '1' > /proc/sys/net/ipv4/ip_forward

The catch is in the first line. Because the iptables code gets executed for both bridged packets and routed packets, we need to make a distinction between the two. We don't really want the bridged frames/packets to be masqueraded. If we omit the first line then everything will work too, but things will happen differently. Let's say 172.16.1.2 pings 172.16.1.4. The bridge receives the ping request and will transmit it through its eth1 port after first masquerading the IP address. So the packet's source IP address will now be 172.16.1.1 and 172.16.1.4 will respond to the bridge. Masquerading will change the IP destination of this response from 172.16.1.1 to 172.16.1.4. Everything works fine. But it's better not to have this behaviour. Thus, we use the first line to avoid this. Note that if we would want to filter the connections to and from the Internet, we would certainly need the first line so we don't filter the local connections as well.

/tmp/nat_rules uses the first line... sort of... hmm.


-A POSTROUTING -o eth1 ! -s <WANIP> -j MASQUERADE
-A POSTROUTING -o br0 -s 192.168.1.0/24 -d 192.168.1.0/24 -j MASQUERADE

[Oleg]

Are you talking about section 7 of the site you showed me? The default rules avoid the problem mentioned there:


/tmp/nat_rules uses the first line... sort of... hmm.


-A POSTROUTING -o eth1 ! -s <WANIP> -j MASQUERADE
-A POSTROUTING -o br0 -s 192.168.1.0/24 -d 192.168.1.0/24 -j MASQUERADE
Yes, exactly. These are conflicting one. Also, most likely bridging speed will decrease, as iptables needs time to process this (too many chains are get traversed if you've seen a picture).

[tomilius]

Yeah. There are actually problems with the default firewall rules (and the slowness has started to return even on my own), you're right. Sorry about that. Guess my post-firewall rules just don't have issues. There's something to fix! :)

UPDATE: Suppose this project is closed... ebtables causes much too much slowness on the WL-500g as of now.

[myxal]

I want to (multicast) stream DVB-T TV stream (5 stations, ~20 Mbps) over the (wired) network. I didn't expect the BCM hardware switch to recognize and deal with multicast, but it turns out that linux-bridge (the one that connects LAN and WLAN) doesn't do this either.

My question would be - is it possible to prevent the wired LAN multicast from overwhelming the WiFi without making LAN and WLAN separate network subnets (=taking down the linux bridge) (I want to keep that for instant fail-over for Linux clients, once I get to it ;) ). It would be OK to filter multicast altogether and have it only on wired LAN. My googling around suggests this would need ebtables, is that correct or am I missing how the iptables and bridging in Linux works? I haven't connected any storage to the router and thus haven't installed any packages or even seen what's available.

Any ideas and helpful suggestions are appreciated.

[myxal]

Googling some more, the way to accomplish what I'm going for (having bridge traffic go through ip-tables) is to use something called bridge-nf (http://ebtables.sourceforge.net/documentation/what.html), which is reportedly working for 2.4 kernel - any ideas on this? Is it included or do I need to patch the kernel?

The so-called bridge-nf code makes iptables see the bridged IP packets and enables transparent IP NAT.