Re: BUG somewhere in NAT mechanism [was: my linux box does not learn from redirects]

Kevin Buhr (buhr@telus.net)
12 Apr 2003 22:00:22 -0700


Maciej Soltysiak <solt@dns.toxicfilms.tv> writes:
>
> In a nutshell:
> - iptable_nat, _may_ cause the box to ignore icmp redirects (maybe other
> things too)

It looks like the relevant bit of code is:

ip_nat_core.c:881 (in 2.4.20)
/* Redirects on non-null nats must be dropped, else they'll
start talking to each other without our translation, and be
confused... --RR */
if (hdr->type == ICMP_REDIRECT) {
/* Don't care about races here. */
if (info->initialized
!= ((1 << IP_NAT_MANIP_SRC) | (1 << IP_NAT_MANIP_DST))
|| info->num_manips != 0)
return NF_DROP;
}

This looks wrong. It's true that you don't want to translate the
redirect and pass it on after NATting, the way you would with a "host
unreachable" packet. But if it was originally directed at you, you
don't just want to drop it, you want to act on it yourself.

In particular, an ICMP redirect originally directed to one of your own
interfaces whose internal packet belongs to a source NATted connection
should have the inner packet (which looks like it came from you)
reverse source NATted (so it looks like it came from the machine you
NATted it for) but the outer packet left untouched so it can be
delivered locally to the kernel.

Any thoughts?

-- 
Kevin <buhr@telus.net>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/