Re: ICMP broken in 2.6.13-rc5

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:

quoted

On Sat, Aug 06, 2005 at 02:08:15AM +0400, Vladimir B. Savkin wrote:

quoted

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?

Ok, I re-thought.  Given the following assumptions (combined from your
three mails):

1) tcp/udp packets are matched by NOTRACK
2) icmp errors for packets in '1' are matched by NOTRACK
3) there are no NAT rules that affect the packets in '1' and '2'

I see a case where packets get corrupted within iptable_nat.  Please try
the attached (untested) patch attached to my mail.

Still, my initial comments about this being an invalid setup upholds.
The NAT code needs to see all packets/connections in order to learn
about used port/ip tuples.  Otherwise, when allocating a tuple, it could
reuse a tuple that is already used by a non-NAT'ed connection.

So using nat in combination with NOTRACK should be prevented.  I'll hack
up a patch for that, too.

-- 
- Harald Welte [off-list ref]          	        http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)