From: "Taylor, Grant" <gtaylor@riverviewtech.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Troubles DNATing UDP
Date: Fri, 10 Nov 2006 16:31:50 +0000 [thread overview]
Message-ID: <4554A976.9030808@riverviewtech.net> (raw)
In-Reply-To: <1162910458.32208.44.camel@localhost.localdomain>
Покотиленко Костик 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
next prev parent reply other threads:[~2006-11-10 16:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-07 14:40 [LARTC] Troubles DNATing UDP
2006-11-10 11:37 `
2006-11-10 16:31 ` Taylor, Grant [this message]
2006-11-13 7:33 `
2006-11-14 19:02 `
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4554A976.9030808@riverviewtech.net \
--to=gtaylor@riverviewtech.net \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.