From: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
To: netfilter@lists.netfilter.org
Subject: Re: Why is my nat pre chain being bypassed by streaming udp?
Date: Wed, 20 Dec 2006 17:10:08 +0100 [thread overview]
Message-ID: <45896060.6000301@plouf.fr.eu.org> (raw)
In-Reply-To: <458844AD.9000308@jrmy.net>
Hello,
Jeremy Freeman a écrit :
>
> We receive streaming udp traffic from two sources destined for port
> 8302. They are always sending this traffic whether are box is on or not.
> Just keeps on coming.
> We want to split off the traffic from one of the sources and redirect it
> to port 9302.
>
> With every other chain empty and with an ACCEPT policy:
>
> iptables -t nat -A PREROUTING -p udp -s <source2 ip> --dport 8302 -j
> REDIRECT --to-ports 9302
>
> however, traffic from source2 keeps on hitting 8302.
>
> Doing a iptables -t nat -L -n -v shows:
>
> 0 0 REDIRECT udp -- * * <source2 ip>
> 0.0.0.0/0 udp dpt:8302 redir ports 9302
>
> So the traffic is never getting picked up by the chain.
>
> Even doing a general rule in the nat PREROUTING with no target shows
> that no traffic is hitting:
>
> 0 0 udp -- * * <source2 ip> 0.0.0.0/0
>
> This is a very simple box with only 1 interface (eth0).
>
> I thought this may be due to connection tracking
Yes. When a packet is related to an existing connection, it skips the
'nat' chains.
> so I added a raw entry to NOTRACK the traffic also:
>
> Chain PREROUTING (policy ACCEPT 90101 packets, 12M bytes)
> 9491 1333K NOTRACK all -- * * <source2 ip> 0.0.0.0/0
>
> So I see the raw chain is picking it up.. But it is skipping past the
> nat chain.
This is because NAT operation needs the connection tracking. So packets
not initiating a new connection, including packets in the INVALID state
or matching a NOTRACK rule, also skip the 'nat' chains.
For the REDIRECT rule to take effect, it must be installed before
receiving the first packet it is supposed to match, e.g. before the
related network interface is activated.
The NOTRACK rule was a good idea, but you needed to wait until the
conntrack entry expires (check in /proc/net/ip_conntrack, it can take a
few minutes for UDP traffic), then remove the NOTRACK rule so the next
packet creates a new connection and goes through the nat rules.
prev parent reply other threads:[~2006-12-20 16:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-19 19:59 Why is my nat pre chain being bypassed by streaming udp? Jeremy Freeman
2006-12-20 16:10 ` Pascal Hambourg [this message]
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=45896060.6000301@plouf.fr.eu.org \
--to=pascal.mail@plouf.fr.eu.org \
--cc=netfilter@lists.netfilter.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.