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>
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>
> > 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?If your HW UDP pinger''s default gateway is your natting firewall, try to ping directly the 192.168.1.2 web server. If default gateway is another router, try adding the route 192.168.1.0/25 to you HW pingers and ping directly 192.168.1.2. If this is not possible (and you are UDP pinging you firewall) open dport 4000 udp in INPUT chain on your firewall and do natting: iptables -t filter -A INPUT -p udp -m udp -s 10.10.0.0/16 -d 10.10.100.1 --dport 4000 -j ACCEPT iptables -t nat -A PREROUTING -p udp -m udp -s 10.10.0.0/16 -d 10.10.100.1 --dport 4000 -j DNAT --to-destination 192.168.1.2 This way 192.168.1.2 host should receive udp packets coming from the firewall. My setup is running smoothly with UDP and NAT, I''m using with playstation online games... Hope this help. Bye, Dino. -- dAm2K, you know I''m there!
Покотиленко Костик 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: 74Hum...> 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. . . .
В Птн, 10/11/2006 в 16:39 +0100, dAm2K пишет:> > > 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? > > If your HW UDP pinger''s default gateway is your natting firewall, try > to ping directly the 192.168.1.2 web server. If default gateway is > another router, try adding the route 192.168.1.0/25 to you HW pingers > and ping directly 192.168.1.2.That would probably help, but it is not desirable. The topology may change, so it''s better ping the closest roouter and to natting in it.> If this is not possible (and you are UDP pinging you firewall) open > dport 4000 udp in INPUT chain on your firewall and do natting: > > iptables -t filter -A INPUT -p udp -m udp -s 10.10.0.0/16 -d > 10.10.100.1 --dport 4000 -j ACCEPT > iptables -t nat -A PREROUTING -p udp -m udp -s 10.10.0.0/16 -d > 10.10.100.1 --dport 4000 -j DNAT --to-destination 192.168.1.2 > > This way 192.168.1.2 host should receive udp packets coming from the firewall.This is what I''ve done. But, packets are reaching INPUT chain, counters of the first rule are increasing, and packets are not reaching second rule, it''s counters are zero all the time. And DNAT''ing not working :/> My setup is running smoothly with UDP and NAT, I''m using with > playstation online games... > > Hope this help. Bye, Dino. >-- Покотиленко Костик <casper@meteor.dp.ua>
В Птн, 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>
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=10.10.100.23 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.23 sport=4000 dport=4000 use=1 udp 17 28 src=10.10.100.21 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=10.10.100.1 dst=10.10.100.21 sport=4000 dport=4000 use=2 udp 17 29 src=10.10.100.22 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.22 sport=4000 dport=4000 use=1 (note this "src=10.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=10.10.100.23 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.23 sport=4000 dport=4000 use=1 udp 17 28 src=10.10.100.21 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.21 sport=4000 dport=4000 use=1 udp 17 29 src=10.10.100.22 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.22 sport=4000 dport=4000 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>