Losing connection between nat and filter tables

Losing connection between nat and filter tables

[Bruno de Paula Larini]

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!

Re: Losing connection between nat and filter tables

[Anton Danilov]

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



-- 
Anton.

Re: Losing connection between nat and filter tables

[Bruno de Paula Larini]

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

Re: Losing connection between nat and filter tables

[Anton Danilov]

I think your trouble in the routing.

What is your second gateway on the eth2 interface?

Replied packets are going through default route, not eth2 iface.

You should use PBR for solve this trouble:
ip route add 0/0 via 180.1.2.1 dev eth1 table 1
ip rule add from 180.1.2.11 lookup table 1 pref 10
ip route add 0/0 via <gw2-ip> dev eth2 table 2
ip rule add from 180.1.2.12 lookup table 2 pref 20

Next step of the troubleshooting is run tcpdump.
And other next step is usage of the TRACE target to detail packet path
inside netfilter chains.

2014-05-09 20:12 GMT+04:00 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
>>
>>
>>
>
>



-- 
Anton.

Re: Losing connection between nat and filter tables

[Bruno de Paula Larini]

No deal yet. After inserting the new routing tables and rules it didn't 
really change anything.
The eth2 doesn't have a gateway set in the config file, only eth1 have 
it. Plus, these two interfaces are in the same subnet and there's only 
one gateway on it (180.1.2.1).

[root@firewall ~]# ip route show table T1
default via 180.1.2.1 dev eth1

[root@firewall ~]# ip route show table T2
default via 180.1.2.1 dev eth2

[root@firewall ~]# ip rule show
0:      from all lookup local
10:     from 180.1.2.11 lookup T1
20:     from 180.1.2.12 lookup T2
32766:  from all lookup main
32767:  from all lookup default

(I had to add the tables T1 and T2 in the file /etc/iproute2/rt_tables)

Even so, I see it reach the PREROUTING chain in eth2 but it still 
disappears after that. Connections reaching in the eth1 still works.

There's something else to try? Or should I debug using tcpdump or the 
TRACE target? Could you instruct me how to do that?
Thanks again.

Em 9/5/2014 13:48, Anton Danilov escreveu:
> I think your trouble in the routing.
>
> What is your second gateway on the eth2 interface?
>
> Replied packets are going through default route, not eth2 iface.
>
> You should use PBR for solve this trouble:
> ip route add 0/0 via 180.1.2.1 dev eth1 table 1
> ip rule add from 180.1.2.11 lookup table 1 pref 10
> ip route add 0/0 via <gw2-ip> dev eth2 table 2
> ip rule add from 180.1.2.12 lookup table 2 pref 20
>
> Next step of the troubleshooting is run tcpdump.
> And other next step is usage of the TRACE target to detail packet path
> inside netfilter chains.
>
> 2014-05-09 20:12 GMT+04:00 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
>>>
>>>
>>
>
>

Re: Losing connection between nat and filter tables

[Mart Frauenlob]

On 09.05.2014 23:07, netfilter-owner@vger.kernel.org wrote:
> No deal yet. After inserting the new routing tables and rules it didn't
> really change anything.
> The eth2 doesn't have a gateway set in the config file, only eth1 have
> it. Plus, these two interfaces are in the same subnet and there's only
> one gateway on it (180.1.2.1).
>
> [root@firewall ~]# ip route show table T1
> default via 180.1.2.1 dev eth1
>
> [root@firewall ~]# ip route show table T2
> default via 180.1.2.1 dev eth2
>
> [root@firewall ~]# ip rule show
> 0:      from all lookup local
> 10:     from 180.1.2.11 lookup T1
> 20:     from 180.1.2.12 lookup T2
> 32766:  from all lookup main
> 32767:  from all lookup default
>
> (I had to add the tables T1 and T2 in the file /etc/iproute2/rt_tables)
>
> Even so, I see it reach the PREROUTING chain in eth2 but it still
> disappears after that. Connections reaching in the eth1 still works.
>
> There's something else to try?

Check values of /proc/sys/net/ipv4/conf/*/rp_filter
and disable them.
To use the TRACE target just put a -j TRACE on the desired place.

Re: Losing connection between nat and filter tables

[Bruno de Paula Larini]

Wow, thank you Mart! I didn't really think that the rp_filter would have 
anything to do with it, but in fact it had! Even though I had disabled 
for "all" interfaces, it seems that the rp_filter files for each 
interface overlaps "all".
So,

echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter

solved the problem of disappearing packets.

But unlike the eth1 interface, the RELATED state isn't allowing (or 
recognizing) the data channel. After doing a DNAT from port 49152 to 
65535, the default data ports for MS FTP, I can now successfully connect 
through the second interface. I don't think there's a workaround for 
that, right?
Even so, I'm glad you guys could help me.
Thanks a lot!


Em 09/05/2014 18:32, Mart Frauenlob escreveu:
> On 09.05.2014 23:07, netfilter-owner@vger.kernel.org wrote:
>> No deal yet. After inserting the new routing tables and rules it didn't
>> really change anything.
>> The eth2 doesn't have a gateway set in the config file, only eth1 have
>> it. Plus, these two interfaces are in the same subnet and there's only
>> one gateway on it (180.1.2.1).
>>
>> [root@firewall ~]# ip route show table T1
>> default via 180.1.2.1 dev eth1
>>
>> [root@firewall ~]# ip route show table T2
>> default via 180.1.2.1 dev eth2
>>
>> [root@firewall ~]# ip rule show
>> 0:      from all lookup local
>> 10:     from 180.1.2.11 lookup T1
>> 20:     from 180.1.2.12 lookup T2
>> 32766:  from all lookup main
>> 32767:  from all lookup default
>>
>> (I had to add the tables T1 and T2 in the file /etc/iproute2/rt_tables)
>>
>> Even so, I see it reach the PREROUTING chain in eth2 but it still
>> disappears after that. Connections reaching in the eth1 still works.
>>
>> There's something else to try?
>
> Check values of /proc/sys/net/ipv4/conf/*/rp_filter
> and disable them.
> To use the TRACE target just put a -j TRACE on the desired place.
>
>
>
>
>

Re: Losing connection between nat and filter tables

[Pascal Hambourg]

Hello,

Bruno de Paula Larini a écrit :
> Wow, thank you Mart! I didn't really think that the rp_filter would have 
> anything to do with it, but in fact it had!

Of course it does, and it's all your fault.
Either eth1 and eth2 are actually connected to the same network and
connecting several interfaces to the same network is wrong and useless
in most cases, or they are not and defining the same subnets on several
interfaces which are connected to different networks is wrong. In either
case, it's wrong. Why did you do so ?

> Even though I had disabled 
> for "all" interfaces, it seems that the rp_filter files for each 
> interface overlaps "all".

It doesn't overlap. Both values are combined using the MAX operator.

  rp_filter functional value for $iface = MAX (all, $iface)

All this and much more is detailed in ip-sysctl.txt.

> But unlike the eth1 interface, the RELATED state isn't allowing (or 
> recognizing) the data channel. After doing a DNAT from port 49152 to 
> 65535, the default data ports for MS FTP, I can now successfully connect 
> through the second interface.

I'm afraid that's because you messed with the FTP control port. By
default the FTP conntrack monitors only the port 21. You can either
specify both 21 and 2121 in the port= option when you load the
nf_conntrack_ftp module, or DNAT the second address to an IP alias
address assigned to the same server, so that you don't need to change
the port.

Re: Losing connection between nat and filter tables

[Bruno de Paula Larini]

Hi Pascal, thank you for clarifying the behavior of the rp_filter. And 
yes, the two interfaces are in the same network, but it's a limitation 
that our ISP imposes to us, as we have a limited range of public IPs in 
only one /28 subnet. The objective this "messy" configuration is that 
two different groups of users have access to different FTP sites without 
having to set a non default port. My only choice was to do a DNAT based 
on the destination IP (even though they are on the same network).
Would you do that in a different way? I really apreciate your help!

Em 10/5/2014 14:21, Pascal Hambourg escreveu:
> Hello,
>
> Bruno de Paula Larini a écrit :
>> Wow, thank you Mart! I didn't really think that the rp_filter would have
>> anything to do with it, but in fact it had!
> Of course it does, and it's all your fault.
> Either eth1 and eth2 are actually connected to the same network and
> connecting several interfaces to the same network is wrong and useless
> in most cases, or they are not and defining the same subnets on several
> interfaces which are connected to different networks is wrong. In either
> case, it's wrong. Why did you do so ?
>
>> Even though I had disabled
>> for "all" interfaces, it seems that the rp_filter files for each
>> interface overlaps "all".
> It doesn't overlap. Both values are combined using the MAX operator.
>
>    rp_filter functional value for $iface = MAX (all, $iface)
>
> All this and much more is detailed in ip-sysctl.txt.
>
>> But unlike the eth1 interface, the RELATED state isn't allowing (or
>> recognizing) the data channel. After doing a DNAT from port 49152 to
>> 65535, the default data ports for MS FTP, I can now successfully connect
>> through the second interface.
> I'm afraid that's because you messed with the FTP control port. By
> default the FTP conntrack monitors only the port 21. You can either
> specify both 21 and 2121 in the port= option when you load the
> nf_conntrack_ftp module, or DNAT the second address to an IP alias
> address assigned to the same server, so that you don't need to change
> the port.
>
>

Re: Losing connection between nat and filter tables

[Pascal Hambourg]

Bruno de Paula Larini a écrit :
> yes, the two interfaces are in the same network, but it's a limitation 
> that our ISP imposes to us, as we have a limited range of public IPs in 
> only one /28 subnet. The objective this "messy" configuration is that 
> two different groups of users have access to different FTP sites without 
> having to set a non default port.

But why did you connect two interfaces to the same network ? If you need
two public IP adresses on the box, couldn't you just assign them to the
same interface ?

> Would you do that in a different way?

If possible, I would assign the two public IP addresses to the same
interface. And I would also assign two private addresses to the
(interface of the) final server. Then I would setup two FTP server
instances to listen on one different private address and port 21 each,
and DNAT each public IP address to the corresponding private address.
This way you would not need to mangle the FTP ports.

Re: Losing connection between nat and filter tables

[Mart Frauenlob]

On 10.05.2014 02:31, Bruno de Paula Larini wrote:
> Wow, thank you Mart! I didn't really think that the rp_filter would have
> anything to do with it, but in fact it had! Even though I had disabled
> for "all" interfaces, it seems that the rp_filter files for each
> interface overlaps "all".
> So,
>
> echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter
>
> solved the problem of disappearing packets.
>
> But unlike the eth1 interface, the RELATED state isn't allowing (or
> recognizing) the data channel. After doing a DNAT from port 49152 to
> 65535, the default data ports for MS FTP, I can now successfully connect
> through the second interface. I don't think there's a workaround for
> that, right?
> Even so, I'm glad you guys could help me.
> Thanks a lot!
>

-t raw -j CT --helper ftp-xyz (where xyz is your desired port number).