All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.