Re: ICMP packets associated with NAT connections sent out wrong interface?

[Patrick McHardy <kaber@trash.net>]

Yasuyuki KOZAKAI wrote:
> From: Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>
> Date: Sun, 08 Jul 2007 02:28:54 +0900 (JST)
> 
> 
>>From: Patrick McHardy <kaber@trash.net>
>>Date: Sat, 7 Jul 2007 17:34:49 +0200 (CEST)
>>
>>>The local ICMP tracking is basically useless nowadays since we always
>>>manually attach the conntrack reference from the original packet
>>>(exactly because of the half-done double NAT FIXME quoted above).
>>>But this is an interesting case, the connection tracking code itself
>>>thought the RST was invalid, but ICMP tracking will still associate
>>>the ICMP containing the RST with the original connection. I'm wondering
>>>whether it should really do that. In case it shouldn't, just removing
>>>all locally generated ICMP special-casing should also fix the bug,
>>>right?
>>
>>At first I thought so. But I didn't come up with any bad situation caused
>>by returning ICMP error to such invalid packets.
> 
> 
> Can kernel correctly return ICMP error without conntrack in this case ?
> If so, I agree. (maybe yes, I'll check it after waking up).


All locally generated ICMP errors are already associated with the
original conntrack and packets skip connection tracking. The
only locally generated ICMP packets that are handled by conntrack
are errors for INVALID packets.