Покотиленко Костик 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@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
