Re: UDP packets sent with wrong source address after routing change [AV#3431]

[Stephen Clark <sclark46@earthlink.net>]

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)