On Sat, Aug 06, 2005 at 01:25:43PM +0400, Vladimir B. Savkin wrote: > On Sat, Aug 06, 2005 at 11:13:37AM +0200, Harald Welte wrote: > > On Sat, Aug 06, 2005 at 02:08:15AM +0400, Vladimir B. Savkin wrote: > > > I found that it really is NOTRACK who cause? bogus ICMP errors. > > > > 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. 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. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
pgpSphNKlfV0Z.pgp
Description: PGP signature
