On Sat, Aug 06, 2005 at 05:12:01PM +0200, Harald Welte wrote:
> > > Well, this means that your ICMP errors need to be NAT'ed but they
> > > cannot, since the original connection causing the ICMP error did not go
> > > through connection tracking.
> >
> > How so, when there are no NAT rules that can match either source packets
> > or ICMP errors?
>
> 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.
In my case, I have local network and Internet access.
Local traffic (packets which have both src and dst IP belonging
to local prefix) does not need to be NATed or statefully filtered.
So I wanted to use NOTRACK for maximum forwarding performance.
ICMP error were matched by NOTRACK too (in OUTPUT chain of raw table),
as it also has local src and dst. IMO, this means then there should
be no NAT attempts for this ICMP packet...
I think of this as a valuable feature of Linux - using one box
for two or more applications, in my case - local router (no NAT, no
stateful filtering, maximum performance) and Internet gateway (with NAT,
more filtering, maximum control).
> 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.
>
Well, this would break this feature which worked very well for me
with older kernels.
~
:wq
With best regards,
Vladimir Savkin.
-
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
