On Mon, 12 Nov 2012, Chris Wilson wrote: > On Sat, 10 Nov 2012, Jozsef Kadlecsik wrote: > > > 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. > > Not necessarily dynamic routing. Even using pppd (pppoa/pppoe) for one > connection and ethernet for the other can cause this problem. Any case that > changes routing without bringing down the old device can be affected. > > I'm glad you agree that these are actual problems or limitations with > MASQUERADE. > > > 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. > > But I'm sorry that you won't consider having a flag that changes > MASQUERADE's behaviour to automatically change the source address in the > conntrack entry. I don't think changing the source address were a good solution: if MASQUERADE could be changed to handle the cases then the wrong conntrack entries should be deleted. But what would trigger the action? (Routing changed? I do not see such a kernel event but I might missed it.) And more importantly, what would identify the affected entries? I do not see any good answer to those questions. 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
