Hi Jozsef,
On Mon, 12 Nov 2012, Jozsef Kadlecsik wrote:
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.
I propose that:
* when the packet matches an existing conntrack rule, and
* is sent out of an interface that does not list the packet's new (SNAT-to)
source address as one of its IP addresses (i.e. if this were a new
connection, MASQUERADE would not choose this source address), and
* the --update-source-address flag is set on the MASQUERADE target
then update the source address on the conntrack rule to the new one.
That's the same thing that would happen if we deleted the conntrack entry
first: MASQUERADE would choose a new source address and save it in the new
conntrack entry.
Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK
Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.
--
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
