Hi Jozsef, On Mon, Nov 12, 2012 at 08:34:26PM +0100, Jozsef Kadlecsik wrote: > On Mon, 12 Nov 2012, Chris Wilson wrote: > > > 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. > > What do you think about this? > > - add route change notification event to the net core > - add --update-source-address flag to the MASQUERADE target > - add a call for such events to the MASQUERADE target, when > the flag is enabled > > The called function then can scan the conntrack table and for every entry > which has got the update-source-address flag, can check whether the source > IP address should be changed. Those entries are then deleted. It seems to me this can be implemented this from user-space. It would require a new working mode for conntrackd that would: 1) subscribe to route events via rtnl and libmnl. 2) get new interface address for some monitored address, also via rtnl. 3) iterate over the table and remove those entries with outdated IP address. All the infrastructure is ready, and it would not require any kernel upgrade. What do you think about this approach? Regards. -- 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
