Hello, > > 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 explanation! Does this mean that a nat function, realized with a DNAT+SNAT rule pair will not work for many-to-one connections? What I wanted to realize with those rules is that UDP packets received from anywhere (several sources) are forwarded to one concrete destination and the source of the forwarded packets is always changed to the same. If so, would a NOTRACK rule in the raw table help here (don't track those connections)? > > 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 You are right, it was my mistake. It was really the insert_failed column. > 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. > Bye, Kornel Keseru ___________________________________________________________________________ Pénzügyi szolgáltatás és hiteligénylés interneten keresztül a nap 24 órájában az [origo]-n. http://www.klikkbank.hu
