Re: iptables redirect is broken on bridged setup

[Jan Engelhardt]

>iptables -t nat -A PREROUTING -s 172.17.6.44 -d 172.16.42.201 -p tcp --dport 
>9100 -j REDIRECT --to 9123
>
>Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
>       0        0 REDIRECT   tcp  --  *      *       172.17.6.44          172.16.42.201      tcp dpt:9100 redir ports 9123
>
>But now I need to bridge together two eth cards in this machine, and
>suddenly redirect is no longer works.

I somehow have to say this is expected behavior. 

>tcpdump on real interface:
>
>10:44:37.964087 172.17.6.44.1385 > 172.16.42.201.9100: S 4092145578:4092145578(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
>10:44:37.964365 172.17.0.1.9123 > 172.17.6.44.1385: S 520564491:520564491(0) ack 4092145579 win 5840 <mss 1460,nop,nop,sackOK> (DF)
>	reply from wrong address! should be simulated as from 172.16.42.201

Not at all. The interface has more than one addresses, so it is free to choose 
which source address to use - Linux usually takes the first, unless you have 
some routing rules in the route tables.
Your "ip a" output shows 17.0.1 as the first address.

>10:44:37.964493 172.17.6.44.1385 > 172.17.0.1.9123: R 4092145579:4092145579(0) win 0
>	peer didn't understand that

This seems all normal to me, and looks like the port on 17.6.44 is just 
closed.


You also say that the [source or destination?] address should be 16.42.201, 
but why? After all, you are using REDIRECT, not SNAT/DNAT.

>same packets on bridge interface:
>
>10:44:37.964087 172.17.6.44.1385 > 172.17.0.1.9123: S 4092145578:4092145578(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
>	looks like redirect was done before bridging - dst addr is already changed

redirect, and in fact, the whole iptables-nat table, _is_ done before 
bridging, see http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png



Jan Engelhardt
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/