From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Clark Subject: Re: UDP packets sent with wrong source address after routing change [AV#3431] Date: Tue, 13 Nov 2012 09:23:04 -0500 Message-ID: <50A257C8.8050700@earthlink.net> References: <20121110140720.GA9610@1984> <20121112233024.GA15215@1984> Reply-To: sclark46@earthlink.net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jozsef Kadlecsik , Chris Wilson , netfilter-devel@vger.kernel.org To: Pablo Neira Ayuso Return-path: Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]:38336 "EHLO elasmtp-kukur.atl.sa.earthlink.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752860Ab2KMOXL (ORCPT ); Tue, 13 Nov 2012 09:23:11 -0500 In-Reply-To: <20121112233024.GA15215@1984> Sender: netfilter-devel-owner@vger.kernel.org List-ID: On 11/12/2012 06:30 PM, Pablo Neira Ayuso wrote: > 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? > > A similar problem exists in the following scenario: You have two upstream isp that you are doing load balancing by having multiple default routes: default nexthop via 66.xxx.xxx.xxx dev eth1 weight 1 nexthop via 205.xxx.xxx.xxx dev eth2 weight 1 On one of the external interface you have a DNAT to an internal server on a private address. The DNAT makes a conntrack entry that is going to in effect do a SNAT on reponses from the internal server back out to the internet, but the load balancing decision on routing happens before this implicit SNAT so you have packets trying to go out an interface where the source address does not fall in the subnet of that interface. Why is routing decision done before the SNAT? -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)