Harald Welte wrote:
As soon as you load NAT, _all_ connections need to be tracked, since
those with no NAT configured need to "allocate a null binding".
NAT needs to know about all connections, since otherwise it would not be
able to learn about all already-used port/ip tuples.
So independant of the specific ICMP problem you're observing, the
configuration seems broken to me in the first place.
It remains to be questioned, whether we should deal more gracefully with
such a setup, though.
But the discussion like this are one of the reasons why we thought very
hard whether we should include the NOTRACK target into mainline at all.
It is dangerous, and a lot of people will use it in combination and end
up with broken configuration.
I think we should make NOTRACK and NAT an XOR, i.e. only allow one of
them to be enabled at any given time.
I don't see how this can work except on a global scale, which would
mean I can't exclude loopback traffic from tracking on a box that
does NAT. I think dealing with this case correctly (don't break the
ICMP packets) and letting the user make sure he doesn't create rules
that result in collisions is a better solutions.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
