Re: Filtering on bridges

[Jan Engelhardt <jengelh@xxxxxxxxxx>]

On Tuesday 2012-01-03 14:15, Steve Hill wrote:
>
>The following is NOT a description of what actually happens, it is
>what I believe would be a cleaner model than the current system:
>Logically, I would say that routing and bridging are two completely
>different processes, so should have separate chains. i.e. the
>PREROUTING, FORWARD, POSTROUTING and OUTPUT chains should refer
>*only* to traffic that is passing through the IP stack, and there
>should be separate PREBRIDGE, FORWARDBRIDGE, POSTBRIDGE chains for
>the bridged traffic.

The packet *is* being passed through the IP stack - if you don't want
that, set net.bridge.bridge-nf-call-{arptables,ip6tables,iptables}=0.

>The bridge interface (br0) should be seen as just another member of
>the bridge, exactly like the physical NICs.

I don't see the point of this other than confusing the user.
After all, it says everywhere that bridges cannot be members
of bridges.

>So following the above idea, a packet generated by a local process
>would pass though:
>
>iptables:OUTPUT (egress NIC: br0)
>iptables:POSTROUTING (egress NIC: br0)
>ebtables:BROUTING (ingress NIC: br0)
>ebtables:PREROUTING (ingress NIC: br0)

I know there is a saying "after the game is before the game",
but you can't apply that to Linux here.

>iptables:PREBRIDGE (ingress NIC: br0)
>ebtables:FORWARD (ingress NIC: br0, egress NIC: eth0)
>iptables:FORWARDBRIDGE (ingress NIC: br0, egress NIC: eth0)
>iptables:POSTBRIDGE (ingress NIC: br0, egress NIC: eth0)
>ebtables:POSTROUTING (ingress NIC: br0, egress NIC: eth0)

FORWARD and PRE*-logicry is never invoked in the local-output path
by design, simply because there is nothing forwarded here.

> And similarly, a bridged packet would look something like:
> ebtables:BROUTING (ingress NIC: eth1)
> ebtables:PREROUTING (ingress NIC: eth1)
> iptables:PREBRIDGE (ingress NIC: eth1)
> ebtables:FORWARD (ingress NIC: eth1, egress NIC: eth0)
> iptables:FORWARDBRIDGE (ingress NIC: eth1, egress NIC: eth0)
> iptables:POSTBRIDGE (ingress NIC: eth1, egress NIC: eth0)
> ebtables:POSTROUTING (ingress NIC: eth1, egress NIC: eth0)
>
> Unfortunately this isn't what happens :)

The wording PREBRIDGE does not make sense, since the IP level does
not, by abstract fashion, know or care about any bridge. This is why
the IP-level hooks are called xxxROUTING, and skb->dev is set to
"br0", necessiting a special -m physdev "layer-breaker" to get at
the real dev.

If anything, the ebtables hooks {BROUTING, PREROUTING, FORWARD,
OUTPUT, POSTROUTING} would have been called something like {BROUTING,
PREBRIDGE, BRIDGED, OUTPUT, POSTBRIDGE} -- because that it the bridge
terminology set --, but alas, the initial developer did not choose
so.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html