Re: RFC: Disable defered bridge hooks by default

[Tom Eastep <teastep@shorewall.net>]

[-- Attachment #1: Type: text/plain, Size: 3135 bytes --]

Patrick McHardy wrote:

> +Why:	The defered output hooks are a bad layering violation causing
> +	lots of unusual and broken behaviour on bridge devices.
> +	Examples include broken QoS classifation using the MARK or
> +	CLASSIFY targets, broken behaviour with the IPsec policy match,
> +	broken connection tracking with VLAN on a bridge, ...
> +
> +	Their only use is to enable bridge output port filtering within
> +	iptables with the physdev match, which can just as well be done by
> +	combining iptables and ebtables using netfilter marks.

Patrick,

Once again, netfilter marks are the solution of last resort. This is
becoming very painful for those of us who produce general Netfilter
configuration tools. The situation is exacerbated by the fact that
ebtables doesn't support modifying the mark value via logical AND/OR and
the other fwmark consumers (tc, ip) don't allow a mask when testing the
fwmark value.

Be that as it may, I'm having difficulty trying to apply your proposed
approach to Shorewall.

Here's an example of a forwarding rule in Shorewall:

	ACCEPT	foo	bar	tcp	25

'foo' and 'bar' are "zone" names and in a bridged configuration each may
be associated with a different port on a bridge. Today, there is a
single rule that sends all 'foo' -> 'bar' packets to a separate chain
(this isn't the exact rule is but it illustrates the point):

	iptables -A FORWARD -i bridge -o bridge -m physdev \
	--physdev-in <foo port> --physdev-out <bar port> -j foo2bar

Given that the ebtables filter table FORWARD chain is traversed before
the iptables filter table FORWARD chain, that single iptables command
can be replaced by:

	ebtables -A FORWARD -o <bar port> -j mark \
	--set-mark <bar mark> # --or-mark would be real handy here

	iptables -A FORWARD -i <bridge> -o <bridge> -m physdev \
	--physdev-in <foo port> -m mark --mark <bar mark> -j foo2bar

The Shorewall rule listed above then creates:

	iptables -A foo2bar -p tcp --dport 25 -j ACCEPT

At the end of the foo2bar chain is an unconditional rule that is
determined by the effective foo->bar policy specified by the user;
policy values include DROP, REJECT, ACCEPT and CONTINUE (CONTINUE is
used for nested zones).

A similar approach is taken for locally-generated packets. There is a
single rule to direct all 'fw' to 'bar' traffic to the 'fw2bar' chain
("fw" is the default name for the zone comprised of the local system):

	iptables -A OUTPUT -o <bridge> -m physdev \
	--physdev-out <bar port> -j fw2bar

As with forwarding, the fw2bar chain ends with a rule that enforces the
fw->bar policy.

Predictably, the Shorewall rule:

	ACCEPT	fw	bar	tcp	25

generates:

	iptables -A fw2bar -p tcp --dport 25 -j ACCEPT

I see no sensible way to eliminate the --physdev-out usage in the OUTPUT
chain using ebtables/iptables and marking. What am I missing?

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]