On Fri, Feb 16, 2018 at 12:07:06PM +0100, Florian Westphal wrote: > Gregory Vander Schueren <gregory.vanderschue...@tessares.net> wrote: > > [ cc netdev ] > > > If sysctl bridge-nf-call-iptables is enabled, iptables chains are already > > traversed from the bridging code. In such case, tproxy already happened when > > reaching ip_rcv. Thus no need to call skb_orphan as this would actually undo > > tproxy. > > I don't like this because it adds yet another test in fastpath, and for > a use case that has apparently never worked before. > > > We noticed issues when using tproxy with net.bridge.bridge-nf-call-iptables > > enabled. In such case, ip_rcv() basically undo tproxy's job. The following > > patch proposes a fix. > > I question wheter its a good idea to mix tproxy with bridges. > > Tproxy relies on policy routing, but a bridge doesn't route :-) > > I guess you use bridge snat mac mangling to force local delivery of > packets that are otherwise bridged? > > If yes, can you use ebtables brouting instead? > This would bypass the bridge (so no iptables invocation from bridge > prerouting anymore). > > We will try to get rid of nf-call-iptables eventually. > > There might be (more complicated) ways to avoid this problem without > adding code in normal network path, but lets check other options first.
Agreed. If there's a fix for this, that should be away from the fast path, not in ip_rcv(). -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
