ICMP packets associated with NAT connections sent out wrong interface?

Yasuyuki KOZAKAI yasuyuki.kozakai at toshiba.co.jp
Sat Jul 7 19:48:40 CEST 2007


From: Yasuyuki KOZAKAI <yasuyuki.kozakai at toshiba.co.jp>
Date: Sun, 08 Jul 2007 02:28:54 +0900 (JST)

> From: Patrick McHardy <kaber at 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).

-- Yasuyuki Kozakai



More information about the netfilter-devel mailing list