bridge and NAT - ebtables support

Oh, yes. Everything works (communication between WLAN and LAN has no issue whatsoever). I suggest, of course, using the patches from here 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.

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

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.

Quote:

---

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.

---

Quote:

---

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.

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

Quote:

---

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.

Code:

---

-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

---

Quote:

---

Originally Posted by tomilius

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.

Code:

---

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

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.

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.

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?

Quote:

---

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

---