Messages in this thread | | | Date | Sun, 13 Apr 2003 14:25:47 +0200 | From | Patrick McHardy <> | Subject | Re: BUG somewhere in NAT mechanism [was: my linux box does not learn from redirects] |
| |
Kevin Buhr wrote:
>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)) >
Apart from what you're saying, it should be:
if (info->initialized & ((1 << IP_NAT_MANIP_SRC) | (1 << IP_NAT_MANIP_DST))
otherwise (maybe that's what Maciej is seeing) redirects for connections without natbindings will be dropped too.
Bye Patrick
> || 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? > > >
- 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/
| |