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
