lkml.org 
[lkml]   [2003]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: BUG somewhere in NAT mechanism [was: my linux box does not learn from redirects]
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.438 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site