This question already has an answer here:
I have a
host1 that has a WAN interface
220.127.116.11) and a LAN interface
10.41.82.1). Inside the LAN is a
host2 with the IP address
Incoming connections to
18.104.22.168:22 are forwarded to
host2 using the following iptables rules on
root@host1:~# iptables -t nat -A OUTPUT -d 22.214.171.124 -p tcp --dport 22 -j DNAT --to 10.41.82.2:22 root@host1:~# iptables -t nat -A PREROUTING -d 126.96.36.199 -p tcp --dport 22 -j DNAT --to 10.41.82.2:22
This works fine, except when
host2 is trying to access
root@host2:~# telnet 188.8.131.52 22 Trying 184.108.40.206... root@host2:~# ping 220.127.116.11 PING 18.104.22.168 56(84) bytes of data. 64 bytes from 22.214.171.124: icmp_seq=1 ttl=64 time=0.125 ms 64 bytes from 126.96.36.199: icmp_seq=2 ttl=64 time=0.279 ms root@host2:~# tcptraceroute 188.8.131.52 22 traceroute to 184.108.40.206, 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * (and so on)
It seems like the packets are being forwarded in a circle. As you can see, pinging works, so the routes and IP forwarding are set up properly.
What did I do wrong and how can I fix the problem?
As mentioned in BillThor’s response and as is described in the frozentux tutorial on DNAT, I need to add an
SNAT rule. I have done this now (note that I have added the LAN address of
-d, as this rule is applied in
POSTROUTING where the destination of the packet has already been changed):
root@host1:~# iptables -t nat -A POSTROUTING -d 10.41.82.2 -p tcp --dport 22 -j SNAT --to 10.41.82.1
Unfortunately, this does not solve the problem, and everything is still the same as described above. Interestingly, the
SNAT rule never seems to be matched, according to the counters shown when running
iptables -t nat -nvL.
I discovered that when I run
tcpdump -i eth1, even when I run it with parameters irrelevant to this case, such as
tcpdump -i eth1 port 34238, it suddenly works. But only while
tcpdump is running.
What I didn’t mention so far because I thought it was irrelevant is that
eth1 is actually a bridge, and
host2 is a Xen domain. I am starting to suspect that my problem might be related to this.