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

[Patrick McHardy]

Kevin Buhr wrote:

>Maciej Soltysiak <[e-mail]> 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?
>
>  
>