Antonio Ojea <aojea@xxxxxxxxxx> wrote: > > + # This is because nfqueue will delay packet for long enough so that > > + # second packet will not find existing conntrack entry. > > for my own education, > will both packets use the same tuple and get a different dnat destination? > if both packets are enqueued for one second , -d option is > milliseconds, why the conntrack entry will not exist? The conntrack entry is inserted into hash table as last step of postrouting. As packet is held my nf_queue, this insertion is delayed and when second packet arrives it will get its own conntrack entry allocted. Due to numgen+dnat combo, it gets its DNAT'd to a different address. There is extra code in conntrack to handle this case, source tuple is the same, reverse tuple is not (because of conflicting NAT). This rather dns-specific hack inserts both entries, the colliding (second) entry is only inserted in the reply direction, where we can map reply packet back to originating socket. If client sends more packets, they only match the initial/first conntrack entry.
