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. Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary -- 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
