Hello,
I was trying to use a setup with nat and bridge, but conntrack doesn't
work properly (at first I tried rtsp, but since it's an external patch
with some modifications, I used ftp for my tests).
I removed everything but the minimal setup to report this bug :
A) one ftp client, on 192.168.1.0/24 (192.168.1.50 or 192.168.1.5 or
192.168.1.150 or 192.168.1.15, see below)
B) one router doing nat
b1) one interface is on 192.168.1.0/24 with the ftp client (192.168.1.70)
b2) the other interface is on 192.168.2.0/24 with the ftp server
(192.168.2.70 or 192.168.2.7, see below)
C) one ftp server, on 192.168.2.0/24 (192.168.2.50)
To do my tests, I used only one physical interface on the router,
configured with two ip addresses. This interface is either a real
interface or a bridge on top of only this same real interface, for
exemple :
ifconfig eth0 192.168.1.70 up
ifconfig eth0:0 192.168.2.70 up
or :
ifconfig eth0:0 down
brctl addbr br0
brctl addif br0 eth0
ifconfig eth0 0.0.0.0 up
ifconfig br0 192.168.1.70 up
ifconfig br0:0 192.168.2.70 up
the following netfilter configuration is used :
iptables -t nat -A POSTROUTING -d 192.168.2.0/24 -j MASQUERADE
I tried this once with three computers, and the today with only two
computers. But to do this two-computers setup, I had to add another
rule to do the trick :
iptables -t nat -A PREROUTING -d 192.168.2.250 -j DNAT
--to-destination 192.168.2.50
And I connect from the computer with both 192.168.1.50 and
192.168.2.50 to the ftp server 192.168.2.250, the route for
192.168.2.0/24 goes via the router, is natted and comes back.
The behaviour is the same with three distinct computers or with this,
so it's not really interesting here.
What I'm seeing, is that when the bridge is used, and when the output
ip address of the router is longer or smaller than the ip address of
the client, then conntrack doesn't work!
The good address is present after nat_ftp ("wan"-side ip address of
ther router), everything seems to work well but the incoming connexion
from port 20 is not forwarded (RST is replied to the SYN).
If the bridge is not used, or if the two ip addresses have the same
length, then it works as expected.
The kernel used on the router is 2.6.24-rc5-git5, and active ftp is used.
I collected /proc/net/nf_conntrack on each try, if something else is
needed, I'll get what is needed (the packets captures with wireshark
look ok in every case, but maybe someone will need them?).
1) without a bridge
* 192.168.1.50 -> 192.168.1.70 [ nat ] 192.168.2.7 -> 192.168.2.50
ftp works
/proc/net/nf_conntrack :
ipv4 2 tcp 6 118 TIME_WAIT src=192.168.2.50 dst=192.168.2.7
sport=20 dport=51956 packets=5 bytes=334 src=192.168.1.50
dst=192.168.2.250 sport=51956 dport=20 packets=3 bytes=164 [ASSURED]
mark=0 secmark=0 use=1
ipv4 2 tcp 6 431998 ESTABLISHED src=192.168.1.50
dst=192.168.2.250 sport=52709 dport=21 packets=11 bytes=635
src=192.168.2.50 dst=192.168.2.7 sport=21 dport=52709 packets=8
bytes=880 [ASSURED] mark=0 secmark=0 use=2
* 192.168.1.50 -> 192.168.1.70 [ nat ] 192.168.2.70 -> 192.168.2.50
ftp works
/proc/net/nf_conntrack :
ipv4 2 tcp 6 431998 ESTABLISHED src=192.168.1.50
dst=192.168.2.250 sport=52747 dport=21 packets=11 bytes=634
src=192.168.2.50 dst=192.168.2.70 sport=21 dport=52747 packets=8
bytes=880 [ASSURED] mark=0 secmark=0 use=2
ipv4 2 tcp 6 118 TIME_WAIT src=192.168.2.50 dst=192.168.2.70
sport=20 dport=43608 packets=5 bytes=334 src=192.168.1.50
dst=192.168.2.250 sport=43608 dport=20 packets=3 bytes=164 [ASSURED]
mark=0 secmark=0 use=1
* 192.168.1.5 -> 192.168.1.70 [ nat ] 192.168.2.7 -> 192.168.2.50
ftp works
/proc/net/nf_conntrack :
ipv4 2 tcp 6 117 TIME_WAIT src=192.168.2.50 dst=192.168.2.7
sport=20 dport=41758 packets=5 bytes=334 src=192.168.1.5
dst=192.168.2.250 sport=41758 dport=20 packets=3 bytes=164 [ASSURED]
mark=0 secmark=0 use=1
ipv4 2 tcp 6 431997 ESTABLISHED src=192.168.1.5
dst=192.168.2.250 sport=47397 dport=21 packets=11 bytes=633
src=192.168.2.50 dst=192.168.2.7 sport=21 dport=47397 packets=8
bytes=880 [ASSURED] mark=0 secmark=0 use=2
* 192.168.1.5 -> 192.168.1.70 [ nat ] 192.168.2.70 -> 192.168.2.50
ftp works
/proc/net/nf_conntrack :
ipv4 2 tcp 6 431998 ESTABLISHED src=192.168.1.5
dst=192.168.2.250 sport=53851 dport=21 packets=11 bytes=634
src=192.168.2.50 dst=192.168.2.70 sport=21 dport=53851 packets=8
bytes=880 [ASSURED] mark=0 secmark=0 use=2
ipv4 2 tcp 6 118 TIME_WAIT src=192.168.2.50 dst=192.168.2.70
sport=20 dport=51600 packets=5 bytes=334 src=192.168.1.5
dst=192.168.2.250 sport=51600 dport=20 packets=3 bytes=164 [ASSURED]
mark=0 secmark=0 use=1
* 192.168.1.150-> 192.168.1.70 [ nat ] 192.168.2.70 -> 192.168.2.50
ftp works
/proc/net/nf_conntrack :
ipv4 2 tcp 6 431998 ESTABLISHED src=192.168.1.150
dst=192.168.2.250 sport=41108 dport=21 packets=11 bytes=636
src=192.168.2.50 dst=192.168.2.70 sport=21 dport=41108 packets=8
bytes=880 [ASSURED] mark=0 secmark=0 use=2
ipv4 2 tcp 6 118 TIME_WAIT src=192.168.2.50 dst=192.168.2.70
sport=20 dport=35479 packets=5 bytes=334 src=192.168.1.150
dst=192.168.2.250 sport=35479 dport=20 packets=3 bytes=164 [ASSURED]
mark=0 secmark=0 use=1
* 192.168.1.15 -> 192.168.1.70 [ nat ] 192.168.2.70 -> 192.168.2.50
ftp works
/proc/net/nf_conntrack :
ipv4 2 tcp 6 118 TIME_WAIT src=192.168.2.50 dst=192.168.2.70
sport=20 dport=46819 packets=5 bytes=334 src=192.168.1.15
dst=192.168.2.250 sport=46819 dport=20 packets=3 bytes=164 [ASSURED]
mark=0 secmark=0 use=1
ipv4 2 tcp 6 431998 ESTABLISHED src=192.168.1.15
dst=192.168.2.250 sport=44839 dport=21 packets=11 bytes=635
src=192.168.2.50 dst=192.168.2.70 sport=21 dport=44839 packets=8
bytes=880 [ASSURED] mark=0 secmark=0 use=2
2) with a bridge
* 192.168.1.50 -> 192.168.1.70 [ nat ] 192.168.2.7 -> 192.168.2.50
ftp doesn't work
/proc/net/nf_conntrack :
ipv4 2 tcp 6 431998 ESTABLISHED src=192.168.1.50
dst=192.168.2.250 sport=56140 dport=21 packets=13 bytes=796
src=192.168.2.50 dst=192.168.2.7 sport=21 dport=56140 packets=13
bytes=1109 [ASSURED] mark=0 secmark=0 use=1
* 192.168.1.50 -> 192.168.1.70 [ nat ] 192.168.2.70 -> 192.168.2.50
ftp works
/proc/net/nf_conntrack :
ipv4 2 tcp 6 431997 ESTABLISHED src=192.168.1.50
dst=192.168.2.250 sport=34334 dport=21 packets=11 bytes=635
src=192.168.2.50 dst=192.168.2.70 sport=21 dport=34334 packets=8
bytes=880 [ASSURED] mark=0 secmark=0 use=2
ipv4 2 tcp 6 118 TIME_WAIT src=192.168.2.50 dst=192.168.2.70
sport=20 dport=59124 packets=5 bytes=334 src=192.168.1.50
dst=192.168.2.250 sport=59124 dport=20 packets=3 bytes=164 [ASSURED]
mark=0 secmark=0 use=1
* 192.168.1.5 -> 192.168.1.70 [ nat ] 192.168.2.7 -> 192.168.2.50
ftp works
/proc/net/nf_conntrack :
ipv4 2 tcp 6 116 TIME_WAIT src=192.168.2.50 dst=192.168.2.7
sport=20 dport=36148 packets=5 bytes=334 src=192.168.1.5
dst=192.168.2.250 sport=36148 dport=20 packets=3 bytes=164 [ASSURED]
mark=0 secmark=0 use=1
ipv4 2 tcp 6 431996 ESTABLISHED src=192.168.1.5
dst=192.168.2.250 sport=46925 dport=21 packets=11 bytes=633
src=192.168.2.50 dst=192.168.2.7 sport=21 dport=46925 packets=8
bytes=880 [ASSURED] mark=0 secmark=0 use=2
* 192.168.1.5 -> 192.168.1.70 [ nat ] 192.168.2.70 -> 192.168.2.50
ftp doesn't work
/proc/net/nf_conntrack :
ipv4 2 tcp 6 59 CLOSE_WAIT src=192.168.2.50 dst=192.168.2.70
sport=20 dport=60875 packets=4 bytes=282 src=192.168.1.5
dst=192.168.2.250 sport=60875 dport=20 packets=3 bytes=164 [ASSURED]
mark=0 secmark=0 use=1
ipv4 2 tcp 6 431999 ESTABLISHED src=192.168.1.5
dst=192.168.2.250 sport=48877 dport=21 packets=12 bytes=687
src=192.168.2.50 dst=192.168.2.70 sport=21 dport=48877 packets=9
bytes=939 [ASSURED] mark=0 secmark=0 use=2
* 192.168.1.150-> 192.168.1.70 [ nat ] 192.168.2.70 -> 192.168.2.50
ftp doesn't work
/proc/net/nf_conntrack :
ipv4 2 tcp 6 431999 ESTABLISHED src=192.168.1.150
dst=192.168.2.250 sport=33847 dport=21 packets=14 bytes=878
src=192.168.2.50 dst=192.168.2.70 sport=21 dport=33847 packets=14
bytes=1173 [ASSURED] mark=0 secmark=0 use=1
* 192.168.1.15 -> 192.168.1.70 [ nat ] 192.168.2.70 -> 192.168.2.50
ftp works
/proc/net/nf_conntrack :
ipv4 2 tcp 6 431998 ESTABLISHED src=192.168.1.15
dst=192.168.2.250 sport=46792 dport=21 packets=11 bytes=633
src=192.168.2.50 dst=192.168.2.70 sport=21 dport=46792 packets=8
bytes=880 [ASSURED] mark=0 secmark=0 use=2
ipv4 2 tcp 6 118 TIME_WAIT src=192.168.2.50 dst=192.168.2.70
sport=20 dport=56576 packets=5 bytes=334 src=192.168.1.15
dst=192.168.2.250 sport=56576 dport=20 packets=3 bytes=164 [ASSURED]
mark=0 secmark=0 use=1
--
Damien Thébault
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
