lost UDP packets with matching NAT rules

lost UDP packets with matching NAT rules

[Keserű Kornél]

Dear List Members,

I'm using iptables (v1.3.4 on a 2.6.15.3 kernel) in order to NAT incoming 
UDP packets arriving on a single IP:port (1-1 rules in PRE- and 
POSTROUTING chains in the nat table). I found out that packets are 
sometimes lost, therefore I developed a test program for that.
The test program receives an UDP packet from the NAT box (from the 
UDP socket where the iptables are setup) waits until conntrack entries 
time out and then sends back 100 UDP packets from 100 different 
sockets. Iptables should forward the received packets to a given 
destination.
The experience is that only the first packet is forwarded, others are lost 
(neither received locally nor forwarded), altough they are sent from 100 
different ports (but from the same IP). If I list the iptables rules with "-
v" I find that all 100 packets matched the iptables rules (pkts column 
shows 100 in PRE- and POSTROUTING chains).
I suspect, it cannot be a conntrack problem, because I send packets 
from 100 different ports. Or are the packets looked up in conntrack 
table by IP address only?
Other experience is that all 100 packets are lost if I don't wait for 
conntrack to time out before sending back the first packet. I don't 
understand it, because I never send data from the same source 
address where a locally generated packet was sent previously from the 
NAT box. So there can't be such conntrack that describes that 
connection. And the counter in iptables is always incremented, it shows 
100.
How could I find out, why are the packets lost? Is there a log entry 
somewhere that says if an UDP packet was dropped because of... ?

Thank you for your answer!

Best regards,
Kornel Keseru


___________________________________________________________________________
Öntsd képeslapba az érzéseidet! Képeslapok Valentin-napra!
http://www.t-online.hu

Re: lost UDP packets with matching NAT rules

[KOVACS Krisztian]

  Hi,

On Tuesday 14 February 2006 10:34, Keserû Kornél wrote:
> I'm using iptables (v1.3.4 on a 2.6.15.3 kernel) in order to NAT
> incoming UDP packets arriving on a single IP:port (1-1 rules in PRE-
> and POSTROUTING chains in the nat table). I found out that packets are

  Why do you need two rules here? Redirecting incoming UDP packets to a 
single IP:port has nothing to do with POSTROUTING, it's a single rule on 
PREROUTING.

> How could I find out, why are the packets lost? Is there a log entry
> somewhere that says if an UDP packet was dropped because of... ?

  Try monitoring /proc/net/stat/ip_conntrack. I guess the number you find 
in the insert_failed column will match the number of dropped packets.

-- 
 KOVACS Krisztian

Re: lost UDP packets with matching NAT rules

[Keserű Kornél]

Hello,

thanks for your reply! See my comments below.

KOVACS Krisztian <hidden@sch.bme.hu> írta:

> 
>   Hi,
> 
> On Tuesday 14 February 2006 10:34, Keserû Kornél wrote:
> > I'm using iptables (v1.3.4 on a 2.6.15.3 kernel) in order to NAT
> > incoming UDP packets arriving on a single IP:port (1-1 rules in PRE-
> > and POSTROUTING chains in the nat table). I found out that 
packets are
> 
>   Why do you need two rules here? Redirecting incoming UDP packets 
to a 
> single IP:port has nothing to do with POSTROUTING, it's a single rule 
on 
> PREROUTING.

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.

> 
> > How could I find out, why are the packets lost? Is there a log entry
> > somewhere that says if an UDP packet was dropped because of... ?
> 
>   Try monitoring /proc/net/stat/ip_conntrack. I guess the number you 
find 
> in the insert_failed column will match the number of dropped 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 
packet (the first one) was forwarded successfully. Note, that with my 
test program I send packets from 100 different sources within a very 
short time (some milliseconds) to the same IP:port (where iptables is 
setup). Do I overload something with that?

Thanks,
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

Re: lost UDP packets with matching NAT rules

[KOVACS Krisztian]

  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

Re: lost UDP packets with matching NAT rules

[Keserű Kornél]

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

Re: lost UDP packets with matching NAT rules

[KOVACS Krisztian]

  Hi,

On Wednesday 15 February 2006 18.16, Keserû Kornél wrote:
> 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)?

  Unfortunately not. You'd need stateless NAT for UDP, which is not (yet) 
implemented in Netfilter. (But occasionally it would be a really cool and 
useful feature.)

-- 
KOVACS Krisztian