Re: lost UDP packets with matching NAT rules

[KOVACS Krisztian <hidden@sch.bme.hu>]

  Hi,

On Wednesday 15 February 2006 14.18, Keserû Kornél wrote:
> I also have to modify the source of the packets not only the destination
> (I want to realize NAT). Maybe my sentence (about redirection) was
> misleading.

  _That_ is the problem. This way you produce clashing connection tracking 
entries, of which obviously only the first one is confirmed, the rest of 
the packets is dropped. Think again: you send 100 packets, each of them 
from a different source. Each and every packet has a new connection 
tracking entry assigned to them when they arrive at the NAT box. Then on 
PREROUTING you redirect these to the same destination. After this has been 
done it's only the _source_ which differentiates between them, the 
destination is the same. Then, on POSTROUTING you change the source address 
of the packet (and the appropriate field in the conntrack entry) to the 
same, predefined value. Oops, you've just destroyed your last piece of 
information based on which you could differentiate the reply packets 
arriving from the node you've forwarded these packets to.

  For the first packet, the conntrack entry gets confirmed, and the packet 
is forwarded. However, for the rest conntrack is unable to insert their 
entries in the hash table (since there's already an entry there with the 
same reply tuple). Thus the best it can do is dropping those packets.

> Thanks for the hint! I checked it. Strange, that not the "insert_failed"
> but the number in the "dropped" column is incremented with 99. 1

  It's hard to believe. Are you sure that you did not make a mistake pairing 
that number to the appropriate column at the top? Can you maybe paste it 
here?

  First of all, I assume you meant 'drop', as theer's no 'dropped' column in 
that file. However, 'drop' is incremented if a packet is dropped because 
connection tracking failed to allocated the memory for the new connection 
tracking structure. It's very unlikely you can trigger this with 100 UDP 
packets.

-- 
KOVACS Krisztian