* lost UDP packets with matching NAT rules
@ 2006-02-14 9:34 Keserű Kornél
2006-02-14 21:21 ` KOVACS Krisztian
0 siblings, 1 reply; 6+ messages in thread
From: Keserű Kornél @ 2006-02-14 9:34 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: lost UDP packets with matching NAT rules
2006-02-14 9:34 lost UDP packets with matching NAT rules Keserű Kornél
@ 2006-02-14 21:21 ` KOVACS Krisztian
2006-02-15 13:18 ` Keserű Kornél
0 siblings, 1 reply; 6+ messages in thread
From: KOVACS Krisztian @ 2006-02-14 21:21 UTC (permalink / raw)
To: netfilter; +Cc: Keserű Kornél
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: lost UDP packets with matching NAT rules
2006-02-14 21:21 ` KOVACS Krisztian
@ 2006-02-15 13:18 ` Keserű Kornél
2006-02-15 15:15 ` KOVACS Krisztian
0 siblings, 1 reply; 6+ messages in thread
From: Keserű Kornél @ 2006-02-15 13:18 UTC (permalink / raw)
To: KOVACS Krisztian; +Cc: netfilter
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: lost UDP packets with matching NAT rules
2006-02-15 13:18 ` Keserű Kornél
@ 2006-02-15 15:15 ` KOVACS Krisztian
2006-02-15 17:16 ` Keserű Kornél
0 siblings, 1 reply; 6+ messages in thread
From: KOVACS Krisztian @ 2006-02-15 15:15 UTC (permalink / raw)
To: netfilter; +Cc: Keserű Kornél
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: lost UDP packets with matching NAT rules
2006-02-15 15:15 ` KOVACS Krisztian
@ 2006-02-15 17:16 ` Keserű Kornél
2006-02-17 9:43 ` KOVACS Krisztian
0 siblings, 1 reply; 6+ messages in thread
From: Keserű Kornél @ 2006-02-15 17:16 UTC (permalink / raw)
To: KOVACS Krisztian; +Cc: netfilter
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: lost UDP packets with matching NAT rules
2006-02-15 17:16 ` Keserű Kornél
@ 2006-02-17 9:43 ` KOVACS Krisztian
0 siblings, 0 replies; 6+ messages in thread
From: KOVACS Krisztian @ 2006-02-17 9:43 UTC (permalink / raw)
To: Keserű Kornél; +Cc: netfilter
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-02-17 9:43 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-02-14 9:34 lost UDP packets with matching NAT rules Keserű Kornél
2006-02-14 21:21 ` KOVACS Krisztian
2006-02-15 13:18 ` Keserű Kornél
2006-02-15 15:15 ` KOVACS Krisztian
2006-02-15 17:16 ` Keserű Kornél
2006-02-17 9:43 ` KOVACS Krisztian
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.