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@xxxxxxxxxxxxxx>:
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@xxxxxxxxxxxxxx>:
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
