[Xen-bugs] [Bug 746] New: bridge, netloop and netfilter/conntrack woes

[bugzilla-daemon@xxxxxxxxxxxxxxxxxxx]

http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=746

           Summary: bridge, netloop and netfilter/conntrack woes
           Product: Xen
           Version: 3.0 (general)
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Guest-OS
        AssignedTo: xen-bugs@xxxxxxxxxxxxxxxxxxx
        ReportedBy: christophe@xxxxxxxx


The netloop driver doesn't clear the netfilter context on packets passing
through and this can cause trouble with packets passing netfilter twice, one
time in bridging tables and the second time in normal iptables.

Consider a setup like the following:

You have router/nat box with one external interface (eth0) which is not
bridged.
Then there is one additional internal interface (eth1) which is bridged via
xenbr0 where local domU's are attached. The internal bridge xenbr0 is a private
network.

Now the loopback driver exposes one port of xenbr0 as vif0.0 <-> eth1. This
eth1 shall be used as default gateway endpoint for all internal traffic which
is natted to eth0.

This currently fails miserably.

What happens with a packet that entres from any of the xenbr0 attached devices
(domU or from the real eth1 card):

- packet enters from peth1 or vif*.*:
- packet moves on xenbr0
- packet enter bridge netfilter
- packet gets a conntrack associated (!)
- packet leaves xenbr0 via vif0.0
- packet gets via netloop to eth1
- packet enters IP stack
- packet enters netfilter (again)
- packet now ALREADY has a conntrack and thus POSTROUTING is skipped
- packet leaves eth0 with internal IP address instead of natted one

The obvious solution against this problem is to add some
"iptables -t raw -A PREROUTING -i xenbr0 -j NOTRACK" so that connection
tracking is prohibited in bridging tables.
Downside: If you want to conntrack packets between different domU's on the
bridge you need to add IP filters to the NOTRACK rule. You can't use the
routing tables and thus don't know whether the packet will leave via vif0.0 at
that point.

Anyway, when doing this, it STILL doesn't work.
The reason is that nfct isn't cleared in the netloop driver and the packet
enters iptables with the NOTRACK still set, which shouldn't really happen, as
it still prevents the PACKET from entering the actual POSTROUTING masquerade
rule.

The obvious solution is that the loopback really shouldn't transport the
netfilter context as it is bogus with the interfaces on both sides changing and
all. The netfilter context isn't transported via real ethernet interfaces or
netback/netfront either.

I added a

        nf_reset(skb);
        secpath_reset(skb);

before netif_rx(skb);

and now it works.

Note that the NOTRACK on the bridge is still required as the bridging and
normal forwarding netfilter can't both maintain a conntrack.

If we would simply use xenbr0 directly as local ethernet endpoint in dom0 all
these problems would magically disappear. No entering netfilter twice, no
NOTRACK and everything just works as expected.

So I'm asking: Why is it exactly that such a constellation can possibly
deadlock? Is there anything that can be done?

If not, please consider clearing the nf context in the loopback driver as
without it I can't find a working solution at all.

Thanks.


-- 
Configure bugmail: 
http://bugzilla.xensource.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

_______________________________________________
Xen-bugs mailing list
Xen-bugs@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-bugs