ICMP packets associated with NAT connections sent out wrong interface?

[Yasuyuki KOZAKAI]

From: Patrick McHardy <kaber at trash.net>
Date: Sat, 7 Jul 2007 17:34:49 +0200 (CEST)

> > My idea is following.
> >
> > - This TCP reset is not initial packet of TCP connection. If it is initial packet,
> >  no address in ICMP packet should be mangled. Jordan, if you see
> >  /proc/net/netfilter/nf_conntrack, you will find the entry matched the TCP packet.
> >
> > - TCP packet was marked as error packet. Because '--state ESTABLISHED'
> >  didn't match the packet. No conntrack entry wasn't assigned to the
> >  packet. Usually, error log by nf_conntrack_tcp should be generated in
> >  such case, but no message is generated in some cases. I don't know why
> >  this TCP reset was handled as error.
> >
> > - Then ICMP error generated at this router was not assigned to any conntrack entry.
> >
> > - nf_conntarck_icmp.c assigns the ICMP error to the conntrack which matches
> >  the TCP reset. But IP_CT_IS_REPLY didn't set to *ctinfo. This is bug.
> >
> >        h = nf_conntrack_find_get(&innertuple, NULL);
> >        if (!h) {
> >                /* Locally generated ICMPs will match inverted if they
> >                   haven't been SNAT'ed yet */
> >                /* FIXME: NAT code has to handle half-done double NAT --RR  */
> >                if (hooknum == NF_IP_LOCAL_OUT)
> >                        h = nf_conntrack_find_get(&origtuple, NULL);
> 
> 
> 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.

-- Yasuyuki Kozakai