On Sat, Nov 10, 2012 at 10:47:55PM +0100, Jozsef Kadlecsik wrote: > On Sat, 10 Nov 2012, Jan Engelhardt wrote: > > > On Saturday 2012-11-10 15:07, Pablo Neira Ayuso wrote: > > > > >On Thu, Nov 08, 2012 at 06:37:24PM +0000, Chris Wilson wrote: > > >[...] > > >> >>Another option which doesn't violate layering might be to update > > >> >>the NAT rule when the outgoing address is known (after routing), > > >> > > > >> >That is what MASQUERADE is usually for. > > >> > > >> Unfortunately I am using MASQUERADE and this still happens. If it > > >> could just be fixed in the MASQUERADE target that would be a big > > >> win. > > > > > >MASQUERADE already cleans up the entries in the conntrack table once > > >you get your device down, that code is still there in 2.6.18: > > > > > >http://lxr.linux.no/#linux+v2.6.18/net/ipv4/netfilter/ipt_MASQUERADE.c#L111 > > > > It looks like it only catches the case of a changing ifindex. > > > > That may work for PPP links, but if you access the 'net over an > > Ethernet-looking link as is (thankfully) done by cable ISPs, > > the interface will never go away. > > > > The DHCP client will simply change one or more addresses on it -- and > > at the same time I wonder if that makes it a "you should run > > conntrack -F or something from your dhclient.script" case. > > That's also handled by the MASQUERADE target: if the device was downed or > its address deleted, the corresponding conntrack entries are cleaned up. > > But the thread is drifted from the original cases: > > > This only seems to happen when you're using a UDP device behind a Linux > > NAT router, and your routing to the destination host changes, because: > > > > * You bring up a VPN tunnel and the SIP destination is at the other end > > of that tunnel; or > > This case is not handled by MASQUERADE. > > > * Your default route changes because you failover to another provider. > > And this case is also not handled if the original default route device is > still healthy, that is for example when you use some dynamic routing > protocol which detects failure in the routing path. > > I do not see any simple solution except to delete any NATed entry > unconditionally when the routing changes. But that can easily be too much > and may kill valid entries. I do not see it either and flushing the entire table seems to me like way too much. My suggestion is to use conntrack -D ... including the appropriate selectors to delete only affected entries, and those selectors depend on the setup. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
