Why is my nat pre chain being bypassed by streaming udp?

Why is my nat pre chain being bypassed by streaming udp?

[Jeremy Freeman]

I am butting my head here folks for the past few days and hopefully
someone will be able to help me.

Background:

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. They will not do this for us, so we need to use a REDIRECT
rule in the nat table to do this.

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 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.

Does anyone know why this is occurring?
One other thing to note is this traffic is being natted first by a cisco
router. But tcpdump shows it coming in as follows:

11:53:27.133025 IP <source2 ip>.32811 > 192.168.6.165.8302: UDP, length 255
11:53:27.133585 IP <source2 ip>.32811 > 192.168.6.165.8302: UDP, length 74
11:53:27.133876 IP <source2 ip>.32811 > 192.168.6.165.8302: UDP, length 74
11:53:27.335457 IP <source2 ip>.32811 > 192.168.6.165.8302: UDP, length 74
etc

Any help or ideas would be greatly appreciated.

--
Jeremy Freeman


etc etc

Re: Why is my nat pre chain being bypassed by streaming udp?

[Pascal Hambourg]

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.