Mailing List Archive: Iptables and bridging

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.