Re: Iptables and bridging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

Ludovic MARCILLY a écrit :

i have a linux box with three ethernet card. I want to bridge eth0
with eth2 and to have eth1 like a DMZ.

Before, i was using linux-2.4.27 with iptables-1.2.11 and bridge
patch. It was working very weel.

Now, i have updating my kernel to 2.6.21.5 and iptables to version
1.3.7 and it does not work anymore.

In my /var/log/message i can read some :

kernel: physdev match: using --physdev-out in the OUTPUT, FORWARD and
POSTROUTING chains for non-bridged traffic is not supported anymore.

What does it means ? I can't do what i want with iptables? I must use
ebtables ?

In kernel 2.6.18, the message was :

"physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is deprecated and breaks other things, it will be removed in January 2007. See Documentation/feature-removal-schedule.txt for details. This doesn't affect you in case you're using it for purely bridged traffic."

The associated Documentation/feature-removal-schedule.txt states :

What: Bridge netfilter deferred IPv4/IPv6 output hook calling
When: January 2007
Why:  The deferred output hooks are a layering violation causing unusual
      and broken behaviour on bridge devices. Examples of things they
      break include QoS classifation using the MARK or CLASSIFY targets,
      the IPsec policy match and connection tracking with VLANs on a
      bridge. Their only use is to enable bridge output port filtering
      within iptables with the physdev match, which can also be done by
      combining iptables and ebtables using netfilter marks. Until it
      will get removed the hook deferral is disabled by default and is
      only enabled when needed.

And indeed this feature was removed in kernel 2.6.20.
What it means seems rather clear to me. Using --physdev-out for non bridged traffic (i.e. locally generated or forwarded IP packets) going out a bridge interface makes no sense because at the time a packet traverses the OUTPUT, FORWARD or POSTROUTING chains it has not reached the bridge interface yet and the physical output device (bridge port) is unknown. It can only be used on bridged traffic, because the bridging decision which determines the output port is made before the packet enters the FORWARD and POSTROUTING chains.

The suggested workaround is to combine iptables and ebtables rules using marks if matching non bridged traffic according to the output bridge port is needed.



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux