Re: Losing connection between nat and filter tables

[Bruno de Paula Larini <bruno.larini@riosoft.com.br>]

Hello Anton, here you go:

[root@firewall ~]# ip -4 address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
     inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
state UP qlen 1000
     inet 192.168.50.3/24 brd 192.168.50.255 scope global eth0
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
state UP qlen 1000
     inet 180.1.2.11/28 brd 180.1.2.15 scope global eth1
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
state UP qlen 1000
     inet 180.1.2.12/28 brd 180.1.2.15 scope global eth2

[root@firewall ~]# ip -4 route
180.1.2.0/28 dev eth1  proto kernel  scope link  src 180.1.2.11
180.1.2.0/28 dev eth2  proto kernel  scope link  src 180.1.2.12
192.168.50.0/24 dev eth0  proto kernel  scope link  src 192.168.50.3
169.254.0.0/16 dev eth0  scope link  metric 1002
169.254.0.0/16 dev eth1  scope link  metric 1003
169.254.0.0/16 dev eth2  scope link  metric 1004
default via 180.1.2.1 dev eth1

[root@firewall ~]# ip -4 rule
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

Everything is kinda default here.
Thank you.

Em 9/5/2014 12:43, Anton Danilov escreveu:
> Hello Bruno.
> Show please output of commands:
> ip -4 address
> ip -4 route
> ip -4 rule
>
>
> 2014-05-09 18:56 GMT+04:00 Bruno de Paula Larini <bruno.larini@riosoft.com.br>:
>> Hello everyone! This is the users list, right? =)
>>
>> I'm about to deploy a FTP service for my company using iptables for NATing
>> client connections to an internal FTP server. However, there will be two FTP
>> sites hosted on the same server, so in order to route the connections to
>> each FTP site I'm currently using two of our public IP addresses like this:
>>
>> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>> iptables -A FORWARD -d 192.168.50.3 -p tcp --dport 21 -j ACCEPT
>> iptables -A FORWARD -d 192.168.50.3 -p tcp --dport 2121 -j ACCEPT
>>
>> iptables -t nat -A PREROUTING -d 180.1.2.11 -p tcp --dport 21 -j DNAT
>> --to-destination 192.168.50.3
>> iptables -t nat -A PREROUTING -d 180.1.2.12 -p tcp --dport 21 -j DNAT
>> --to-destination 192.168.50.3:2121
>>
>> iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 180.1.2.11
>> iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to-source 180.1.2.12
>>
>> (the FORWARD default policy is DROP; all chains in the nat table are set to
>> ACCEPT)
>>
>> I didn't open up higher ports because the RELATED state should take care of
>> things (or so I think). The default gateway is 180.1.2.1 and the interface
>> set to use it is 180.1.2.11 (eth1). Here are my routes:
>>
>> 180.1.2.0/28 dev eth1  proto kernel  scope link  src 180.1.2.11
>> 180.1.2.0/28 dev eth2  proto kernel  scope link  src 180.1.2.12
>> 192.168.50.0/24 dev eth0  proto kernel  scope link  src 192.168.50.3
>> default via 180.1.2.1 dev eth1
>>
>> After running the above, I can successfully connect to the FTP using the IP
>> 180.1.2.11 in passive mode (the only mode I need). But connecting to
>> 180.1.2.12 will result in a timeout.
>>
>> Logging the client connection with PREROUTING and FORWARD I get this:
>>
>> May  9 09:53:45 firewall kernel: IN=eth2 OUT=
>> MAC=02:45:bd:53:82:78:ae:50:4d:5f:b1:b9:08:00 SRC=177.21.108.6
>> DST=180.1.2.12 LEN=52 TOS=0x00 PREC=0x00 TTL=113 ID=14149 DF PROTO=TCP
>> SPT=50051 DPT=21 WINDOW=8192 RES=0x00 SYN URGP=0
>> *repeats 3 more times before timeout*
>>
>> So, the connection reaches the server, but I don't see it hit the FORWARD
>> chain, while client connections to the other IP (180.1.2.11) logs all the
>> way to the POSTROUTING chain.
>>
>> The only peculiarity is that the iptables machine is virtualized on a
>> XenServer 6.2 platform. I'm using vlans and virtual (bridged) interfaces.
>> The iptables (v1.4.7) is running on a CentOS 6.4 kernel
>> 2.6.32-358.el6.x86_64. Even knowing that it don't have anything to do with
>> it, I've disabled the rp_filter.
>>
>> Right now I'm clueless and that don't even make sense to me =(
>> Am I missing something? Could somebody help me with that?
>> Thank you!
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netfilter" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>