Losing connection between nat and filter tables
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!
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 <[email protected]>:
Quoted 61 lines
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:2121iptables -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.12192.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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 1 line
Anton.
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:
Quoted 71 lines
Hello Bruno.
Show please output of commands:
ip -4 address
ip -4 route
ip -4 rule2014-05-09 18:56 GMT+04:00 Bruno de Paula Larini <[email protected]>:
Quoted 61 lines
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:2121iptables -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.12192.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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <[email protected]>:
Quoted 120 lines
Hello Anton, here you go:
[root@firewall ~]# ip -4 address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWNinet 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 1004default 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 defaultEverything is kinda default here.
Thank you.Em 9/5/2014 12:43, Anton Danilov escreveu:
Quoted 82 lines
Hello Bruno.
Show please output of commands:
ip -4 address
ip -4 route
ip -4 rule2014-05-09 18:56 GMT+04:00 Bruno de Paula Larini
<[email protected]>:Quoted 70 lines
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:2121iptables -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.12192.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 therp_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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 1 line
Anton.
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:
Quoted 136 lines
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 20Next 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 <[email protected]>:
Quoted 117 lines
Hello Anton, here you go:
[root@firewall ~]# ip -4 address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWNinet 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 1004default 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 defaultEverything is kinda default here.
Thank you.Em 9/5/2014 12:43, Anton Danilov escreveu:
Quoted 80 lines
Hello Bruno.
Show please output of commands:
ip -4 address
ip -4 route
ip -4 rule2014-05-09 18:56 GMT+04:00 Bruno de Paula Larini
<[email protected]>:Quoted 69 lines
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:2121iptables -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.12192.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 therp_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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 19 lines · On 09.05.2014 23:07, [email protected] 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
Quoted 6 lines
(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.
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:
Quoted 35 lines · On 09.05.2014 23:07, [email protected] wrote:
Quoted 19 lines
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 defaultQuoted 6 lines
(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.
Hello,
Quoted 2 lines · Bruno de Paula Larini
Wow, thank you Mart! I didn't really think that the
rp_filterwould 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 ?
Quoted 3 lines
Even though I had disabled
for "all" interfaces, it seems that therp_filterfiles 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.
Quoted 4 lines
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.
Quoted 10 lines · Bruno de Paula Larini
Wow, thank you Mart! I didn't really think that the
rp_filterwould have anything to do with it, but in fact it had! Even though I had disabled for "all" interfaces, it seems that therp_filterfiles for each interface overlaps "all".
So,echo 0 >
/proc/sys/net/ipv4/conf/eth2/rp_filtersolved the problem of disappearing packets.
Quoted 8 lines
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).
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:
Quoted 33 lines
Hello,
Quoted 2 lines · Bruno de Paula Larini
Wow, thank you Mart! I didn't really think that the
rp_filterwould 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 ?Quoted 3 lines
Even though I had disabled
for "all" interfaces, it seems that therp_filterfiles for each interface overlaps "all".It doesn't overlap. Both values are combined using the MAX operator.
rp_filterfunctional value for $iface = MAX (all, $iface)All this and much more is detailed in ip-sysctl.txt.
Quoted 4 lines
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_ftpmodule, 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.
Quoted 5 lines · Bruno de Paula Larini
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 ?
Quoted 1 line
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.