[LARTC] Troubles DNATing UDP

[LARTC] Troubles DNATing UDP

[@ 2006-11-07 14:40 UTC (permalink / raw)]

Hi.

I have strange troubles with DNATing UDP packets.

The situation:

1. We have local network 10.10.0.0/16
2. We have a "server network" 192.168.1.0/25 connected with local
network by a router 10.10.100.1 (other ip 192.168.1.1).
3. Web server is located at 192.168.1.2
4. There are HW pingers in the net 10.10.0.0/16 whose do ping
10.10.100.1 every second. The ping is the UDP packet with both source
and destination ports set to 4000.
5. There is software to decode ping packets and produce/update html
report. 

I want to install the ping-analizing software at the web-server
(192.168.1.2) and connect it with localy running apache to have a web
page with ping-report.

As the pingers ping (send UDP packets) to 10.10.100.1 I was trying to
redirect them to 192.168.1.2 by:

iptables -t nat -I PREROUTING 1 -p udp --dport 4000 -j DNAT
--to-destination 192.168.1.2:4000
iptables -I FORWARD -p udp --dport 4000 -d 192.168.1.2 -j ACCEPT

Neither of those rules not catching the packets, they all reach
10.10.100.1 INPUT chain. Those rule counters are zero.

If I do:

iptables -t mangle -I PREROUTING 1 -p udp --dport 4000

this rule catch needed packets, but not in NAT tables! Why?

I tryed same with TCP:

iptables -t nat -I PREROUTING 1 -p tcp --dport 4000 -j DNAT
--to-destination 192.168.1.2:4000
iptables -I FORWARD -p tcp --dport 4000 -d 192.168.1.2 -j ACCEPT

and this works fine, I can see packets at 192.168.1.2 when doing telnet
10.10.100.1 4000 from the localnet.

Here is tcpdump from 10.10.100.1:

# tcpdump -i br0 port 4000 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
16:36:53.202130 IP 10.10.100.23.4000 > 10.10.100.1.4000: UDP, length: 74
16:36:54.092413 IP 10.10.100.21.4000 > 10.10.100.1.4000: UDP, length: 74
16:36:54.143128 IP 10.10.100.22.4000 > 10.10.100.1.4000: UDP, length: 74
16:36:55.291886 IP 10.10.100.23.4000 > 10.10.100.1.4000: UDP, length: 74
16:36:55.545621 IP 10.10.100.22.4000 > 10.10.100.1.4000: UDP, length: 74
16:36:55.743096 IP 10.10.100.21.4000 > 10.10.100.1.4000: UDP, length: 74

Once again, all those packets reach INPUT chain, rules in -t nat -I
PREROUTING not working.

So here is the question: Does the UDP is being DNAT'ed differently
comparing with TCP? What is the difference? How can I DNAT them?

Thanks in advance.

P.S. This king of UDP ping doesn't require responce, its just to see
which remote point is still alive.

-- 
Покотиленко Костик <casper@meteor.dp.ua>

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Troubles DNATing UDP

[@ 2006-11-10 11:37 UTC (permalink / raw)]

Did my message hit the list?

Once again, is there any difference in DNAT'ing TCP and UDP, maybe there
is difference related to different kinds/types of UDP packet?

В Вто, 07/11/2006 в 16:40 +0200, Покотиленко Костик пишет:
> Hi.
> 
> I have strange troubles with DNATing UDP packets.
> 
> The situation:
> 
> 1. We have local network 10.10.0.0/16
> 2. We have a "server network" 192.168.1.0/25 connected with local
> network by a router 10.10.100.1 (other ip 192.168.1.1).
> 3. Web server is located at 192.168.1.2
> 4. There are HW pingers in the net 10.10.0.0/16 whose do ping
> 10.10.100.1 every second. The ping is the UDP packet with both source
> and destination ports set to 4000.
> 5. There is software to decode ping packets and produce/update html
> report. 
> 
> I want to install the ping-analizing software at the web-server
> (192.168.1.2) and connect it with localy running apache to have a web
> page with ping-report.
> 
> As the pingers ping (send UDP packets) to 10.10.100.1 I was trying to
> redirect them to 192.168.1.2 by:
> 
> iptables -t nat -I PREROUTING 1 -p udp --dport 4000 -j DNAT
> --to-destination 192.168.1.2:4000
> iptables -I FORWARD -p udp --dport 4000 -d 192.168.1.2 -j ACCEPT
> 
> Neither of those rules not catching the packets, they all reach
> 10.10.100.1 INPUT chain. Those rule counters are zero.
> 
> If I do:
> 
> iptables -t mangle -I PREROUTING 1 -p udp --dport 4000
> 
> this rule catch needed packets, but not in NAT tables! Why?
> 
> I tryed same with TCP:
> 
> iptables -t nat -I PREROUTING 1 -p tcp --dport 4000 -j DNAT
> --to-destination 192.168.1.2:4000
> iptables -I FORWARD -p tcp --dport 4000 -d 192.168.1.2 -j ACCEPT
> 
> and this works fine, I can see packets at 192.168.1.2 when doing telnet
> 10.10.100.1 4000 from the localnet.
> 
> Here is tcpdump from 10.10.100.1:
> 
> # tcpdump -i br0 port 4000 -n
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
> 16:36:53.202130 IP 10.10.100.23.4000 > 10.10.100.1.4000: UDP, length: 74
> 16:36:54.092413 IP 10.10.100.21.4000 > 10.10.100.1.4000: UDP, length: 74
> 16:36:54.143128 IP 10.10.100.22.4000 > 10.10.100.1.4000: UDP, length: 74
> 16:36:55.291886 IP 10.10.100.23.4000 > 10.10.100.1.4000: UDP, length: 74
> 16:36:55.545621 IP 10.10.100.22.4000 > 10.10.100.1.4000: UDP, length: 74
> 16:36:55.743096 IP 10.10.100.21.4000 > 10.10.100.1.4000: UDP, length: 74
> 
> Once again, all those packets reach INPUT chain, rules in -t nat -I
> PREROUTING not working.
> 
> So here is the question: Does the UDP is being DNAT'ed differently
> comparing with TCP? What is the difference? How can I DNAT them?
> 
> Thanks in advance.
> 
> P.S. This king of UDP ping doesn't require responce, its just to see
> which remote point is still alive.
> 
-- 
Покотиленко Костик <casper@meteor.dp.ua>

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Troubles DNATing UDP

[Taylor, Grant]

Покотиленко Костик wrote:

<snip>

> As the pingers ping (send UDP packets) to 10.10.100.1 I was trying to
> redirect them to 192.168.1.2 by:
> 
> iptables -t nat -I PREROUTING 1 -p udp --dport 4000 -j DNAT
> --to-destination 192.168.1.2:4000
> iptables -I FORWARD -p udp --dport 4000 -d 192.168.1.2 -j ACCEPT

(Before morning coffee...)

One quick question / point.  Your source and destination ports are both 4000 
right?  (I presuming yes.)  Your PREROUTING rule is looking to DNAT any UDP 
traffic that has a destination port of 4000 to 192.168.1.2.  What happens to 
the reply traffic from 192.168.1.2 that is destined to port 4000 on 10.0.x.y?

> Neither of those rules not catching the packets, they all reach
> 10.10.100.1 INPUT chain. Those rule counters are zero.

Hum.  Try adding a rule similar to this:

iptables -t nat -I PREROUTING 1 -p udp --dport 4000 -j LOG

To see if you can match the packets at all.

> If I do:
> 
> iptables -t mangle -I PREROUTING 1 -p udp --dport 4000
> 
> this rule catch needed packets, but not in NAT tables! Why?

I would expect that you could match the packets any where they traverse the 
kernel.

<snip>

> Here is tcpdump from 10.10.100.1:
> 
> # tcpdump -i br0 port 4000 -n
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
> 16:36:53.202130 IP 10.10.100.23.4000 > 10.10.100.1.4000: UDP, length: 74
> 16:36:54.092413 IP 10.10.100.21.4000 > 10.10.100.1.4000: UDP, length: 74
> 16:36:54.143128 IP 10.10.100.22.4000 > 10.10.100.1.4000: UDP, length: 74
> 16:36:55.291886 IP 10.10.100.23.4000 > 10.10.100.1.4000: UDP, length: 74
> 16:36:55.545621 IP 10.10.100.22.4000 > 10.10.100.1.4000: UDP, length: 74
> 16:36:55.743096 IP 10.10.100.21.4000 > 10.10.100.1.4000: UDP, length: 74

Hum...

> Once again, all those packets reach INPUT chain, rules in -t nat -I
> PREROUTING not working.

You appear to be using a bridge interface, not a real network interface. 
(Not that this is a problem.)

Do you have the "Bridged IP/ARP packets filtering" option enabled in the 
kernel?  If you do, this option will enable NetFilter Layer 3 filtering at 
the EBTables Layer 2 level.  I.e. you can use IPTables to filter bridged 
traffic.  In this case you will need to write rules to allow your bridged 
traffic to flow through, as it is dependent on your Table / CHAIN default 
policies.

> So here is the question: Does the UDP is being DNAT'ed differently
> comparing with TCP? What is the difference? How can I DNAT them?

I do not think that the problem is with the protocol(s) per say, but rather 
the filtering that is in place.

Will you please do an iptables-save output so that we can see your entire 
firewall script to better evaluate what is going on.

> Thanks in advance.

No problem.

> P.S. This king of UDP ping doesn't require responce, its just to see
> which remote point is still alive.

Sorry, I have to ask.  How are you going to be able to tell if a point is 
active if you do not get a reply?  Are you looking for some sort of anomaly 
in reply / error (or lack there of) traffic to determine if a point is active?



Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Troubles DNATing UDP

[@ 2006-11-13 7:33 UTC (permalink / raw)]

В Птн, 10/11/2006 в 10:31 -0600, Taylor, Grant пишет:
> Покотиленко Костик wrote:
> 
> <snip>
> 
> > As the pingers ping (send UDP packets) to 10.10.100.1 I was trying to
> > redirect them to 192.168.1.2 by:
> > 
> > iptables -t nat -I PREROUTING 1 -p udp --dport 4000 -j DNAT
> > --to-destination 192.168.1.2:4000
> > iptables -I FORWARD -p udp --dport 4000 -d 192.168.1.2 -j ACCEPT
> 
> (Before morning coffee...)
> 
> One quick question / point.  Your source and destination ports are both 4000 
> right?  (I presuming yes.)  Your PREROUTING rule is looking to DNAT any UDP 
> traffic that has a destination port of 4000 to 192.168.1.2.  What happens to 
> the reply traffic from 192.168.1.2 that is destined to port 4000 on 10.0.x.y?

There is not such traffic as that kind of ping not supposed to do
replay. Explain latter.

> > Neither of those rules not catching the packets, they all reach
> > 10.10.100.1 INPUT chain. Those rule counters are zero.
> 
> Hum.  Try adding a rule similar to this:
> 
> iptables -t nat -I PREROUTING 1 -p udp --dport 4000 -j LOG
> 
> To see if you can match the packets at all.

I did that, nothing is matched. This is strange.

> > If I do:
> > 
> > iptables -t mangle -I PREROUTING 1 -p udp --dport 4000
> > 
> > this rule catch needed packets, but not in NAT tables! Why?
> 
> I would expect that you could match the packets any where they traverse the 
> kernel.
> 
> <snip>
> 
> > Here is tcpdump from 10.10.100.1:
> > 
> > # tcpdump -i br0 port 4000 -n
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol
> > decode
> > listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
> > 16:36:53.202130 IP 10.10.100.23.4000 > 10.10.100.1.4000: UDP, length: 74
> > 16:36:54.092413 IP 10.10.100.21.4000 > 10.10.100.1.4000: UDP, length: 74
> > 16:36:54.143128 IP 10.10.100.22.4000 > 10.10.100.1.4000: UDP, length: 74
> > 16:36:55.291886 IP 10.10.100.23.4000 > 10.10.100.1.4000: UDP, length: 74
> > 16:36:55.545621 IP 10.10.100.22.4000 > 10.10.100.1.4000: UDP, length: 74
> > 16:36:55.743096 IP 10.10.100.21.4000 > 10.10.100.1.4000: UDP, length: 74
> 
> Hum...
> 
> > Once again, all those packets reach INPUT chain, rules in -t nat -I
> > PREROUTING not working.
> 
> You appear to be using a bridge interface, not a real network interface. 
> (Not that this is a problem.)
> 
> Do you have the "Bridged IP/ARP packets filtering" option enabled in the 
> kernel?  If you do, this option will enable NetFilter Layer 3 filtering at 
> the EBTables Layer 2 level.  I.e. you can use IPTables to filter bridged 
> traffic.  In this case you will need to write rules to allow your bridged 
> traffic to flow through, as it is dependent on your Table / CHAIN default 
> policies.

There are alot of other udp and tcp traffic already comming through.

> > So here is the question: Does the UDP is being DNAT'ed differently
> > comparing with TCP? What is the difference? How can I DNAT them?
> 
> I do not think that the problem is with the protocol(s) per say, but rather 
> the filtering that is in place.
> 
> Will you please do an iptables-save output so that we can see your entire 
> firewall script to better evaluate what is going on.

I'll study the situation once again today and send the entire rules if
no luck.

> > Thanks in advance.
> 
> No problem.
> 
> > P.S. This king of UDP ping doesn't require responce, its just to see
> > which remote point is still alive.
> 
> Sorry, I have to ask.  How are you going to be able to tell if a point is 
> active if you do not get a reply?  Are you looking for some sort of anomaly 
> in reply / error (or lack there of) traffic to determine if a point is active?

You should get 1 packet per second from each HW pinger, if you don't get
or get less than 1packet/s from particular HW pinger, then there are
problems with the route to that HW pinger. For debugging purpose it's
possible to ping clients in between and figure out where the problem
starts to take place.

-- 
Покотиленко Костик <casper@meteor.dp.ua>

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Troubles DNATing UDP

[@ 2006-11-14 19:02 UTC (permalink / raw)]

Well, I did more testing/research today...

1. I've found some posts telling about the bug in the kernel prior to
2.6.13 about ip_conntack and UNREPLIED connections probably related to
my problem. Later I've found some posts telling that the bug still
appear in most modern kernels.

2. I tryed to reproduce this problem in other inveronment. I've written
program that sends udp packets (source and destination ports 4000)
similar to those produced by HW pingers. And I felt no problem DNAT'ing
packets sent from 2 machines on both 2.6.8 and 2.6.17 kernels.

While doing that I've mentioned one strange thing. The output of
"tcpdump -v -v" in reproduced case always show different UDP ID for each
packet, while in real case it show the same UDP ID for all HW pingers
for all packets.

Does somebody know that is UDP ID and should it be related to this
problem?

Just in case:

# tcpdump -i br0 port 4000 -v -n
tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 96
bytes
20:58:21.636684 IP (tos 0x0, ttl  64, id 6552, offset 0, flags [none],
length: 102) 10.10.100.22.4000 > 192.168.1.2.4000: UDP, length: 74
20:58:22.888548 IP (tos 0x0, ttl  64, id 6552, offset 0, flags [none],
length: 102) 10.10.100.21.4000 > 192.168.1.2.4000: UDP, length: 74
20:58:23.065247 IP (tos 0x0, ttl  64, id 6552, offset 0, flags [none],
length: 102) 10.10.100.22.4000 > 192.168.1.2.4000: UDP, length: 74
20:58:23.351091 IP (tos 0x0, ttl  64, id 6552, offset 0, flags [none],
length: 102) 10.10.100.23.4000 > 192.168.1.2.4000: UDP, length: 74

3. I've played with the router in real case and found out that the
problem not always appear.

Having the rule:

iptables -t nat -A PREROUTING -d 10.10.100.1 -p udp -m udp --dport 4000
-j DNAT --to-destination 192.168.1.2

and doing ifdown br0, then ifup br0, and looking
in /proc/net/ip_conntrack:

One time I got:

udp      17 29 src\x10.10.100.23 dst\x10.10.100.1 sport@00 dport@00
[UNREPLIED] src\x192.168.1.2 dst\x10.10.100.23 sport@00 dport@00 use=1
udp      17 28 src\x10.10.100.21 dst\x10.10.100.1 sport@00 dport@00
[UNREPLIED] src\x10.10.100.1 dst\x10.10.100.21 sport@00 dport@00 use=2
udp      17 29 src\x10.10.100.22 dst\x10.10.100.1 sport@00 dport@00
[UNREPLIED] src\x192.168.1.2 dst\x10.10.100.22 sport@00 dport@00 use=1

(note this "src\x10.10.100.1" for second rule).  10.10.100.23 and
10.10.100.22 got through.

Several next times I got 2 others to work. And finally I got all of them
to work:

udp      17 29 src\x10.10.100.23 dst\x10.10.100.1 sport@00 dport@00
[UNREPLIED] src\x192.168.1.2 dst\x10.10.100.23 sport@00 dport@00 use=1
udp      17 28 src\x10.10.100.21 dst\x10.10.100.1 sport@00 dport@00
[UNREPLIED] src\x192.168.1.2 dst\x10.10.100.21 sport@00 dport@00 use=1
udp      17 29 src\x10.10.100.22 dst\x10.10.100.1 sport@00 dport@00
[UNREPLIED] src\x192.168.1.2 dst\x10.10.100.22 sport@00 dport@00 use=1

To conclude, right now I have all packets being DNAT'd like I want, but
I guess this is until next reboot :/

-- 
Покотиленко Костик <casper@meteor.dp.ua>

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc