В Птн, 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@xxxxxxxxxxxx> _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
