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?

[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/showf...oup_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).

[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, 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.