0

For some reason my NAT is only allowing connections on the local network. When I ping the local network, the packets come out with the NAT gateway as the source. When I ping the remote network (Internet host etc.), the packet source is the internal IP address for the device and the responses do not get sent back properly. Any ideas about what could be configured incorrectly?

router ~ # iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth2 -j ACCEPT
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 3306 -j ACCEPT
router ~ # iptables -S -t nat
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -o eth0 -j MASQUERADE

The internal network is 192.168.0.0/16 and the external (NAT local) is 10.72.16.0/22.

Updated with information for A.B.

router ~ # ip -br link; ip -4 -br addr; ip route; ip rule
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0             UP             00:15:5d:e8:47:39 <BROADCAST,MULTICAST,UP,LOWER_UP>
eth1             UP             00:15:5d:e8:47:3a <BROADCAST,MULTICAST,UP,LOWER_UP>
eth2             UP             00:15:5d:e8:47:46 <BROADCAST,MULTICAST,UP,LOWER_UP>
sit0@NONE        DOWN           0.0.0.0 <NOARP>
lo               UNKNOWN        127.0.0.1/8
eth0             UP             10.72.16.140/22
eth1             UP             10.72.21.14/22
eth2             UP             192.168.0.1/16
default via 10.72.20.1 dev eth1
default via 10.72.16.1 dev eth0
10.72.16.0/22 dev eth0 proto kernel scope link src 10.72.16.140
10.72.20.0/22 dev eth1 proto kernel scope link src 10.72.21.14
192.168.0.0/16 dev eth2 proto kernel scope link src 192.168.0.1
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

And the same from an internal host:

int_host ~ # ip -br link; ip -4 -br addr; ip route; ip rule
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0             UP             52:69:6e:00:81:95       <BROADCAST,MULTICAST,UP,LOWER_UP>
usb0             DOWN           52:69:6e:00:00:00 <NO-  CARRIER,BROADCAST,MULTICAST,UP>
lo               UNKNOWN        127.0.0.1/8
eth0             UP             192.168.0.5/16
usb0             DOWN           192.168.127.5/24 169.254.0.1/16
default via 192.168.0.1 dev eth0
169.254.0.0/16 dev usb0 proto kernel scope link src 169.254.0.1 linkdown
192.168.0.0/16 dev eth0 proto kernel scope link src 192.168.0.5
192.168.127.0/24 dev usb0 proto kernel scope link src 192.168.127.5 linkdown
RTNETLINK answers: Address family not supported by protocol
Dump terminated

Pinging from the internal host to an external (local) host:

int_host ~ # ping 10.72.16.50
PING 10.72.16.50 (10.72.16.50) 56(84) bytes of data.
64 bytes from 10.72.16.50: icmp_seq=1 ttl=127 time=1.37 ms
^C

Pinging from the internal host to an external (external) host:

int_host ~ # ping 172.18.221.227
PING 172.18.221.227 (172.18.221.227) 56(84) bytes of data.
^C
--- 172.18.221.227 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7243ms

Wireshark shows that the ping came with the source being the internal IP address of the internal host:

4842    60.182197   192.168.0.5 172.18.221.227  ICMP    98  Echo (ping) request  id=0x567d, seq=7/1792, ttl=62 (reply in 4843)
4843    60.182365   172.18.221.227  192.168.0.5 ICMP    98  Echo (ping) reply    id=0x567d, seq=7/1792, ttl=128 (request in 4842)

As expected the response never gets sent back because it goes to the non-existent 192.168.0.5 host instead of the router at 10.72.16.140 (and then to the internal 192.168.0.5 address).

Improve this question
3
  • can you add additional informations in the question? output of ip -br link; ip -4 -br addr; ip route; ip rule so there's the whole picture? and then examples, with IPs of what happens in both cases? Commented Apr 28, 2018 at 11:10
  • you have a strange setting with two default routes set: this is rarely working correctly. Now your MASQUERADE rule is for eth0 only. So when pinging something going out through eth1 (as 172.18.221.227) there is no NAT performed. An access to internet won't work: it's using the first default route via eth1 which doesn't get any NAT. The real question you have to ask yourself is: why are there two default routes? only one (the first in the list) will be used. There should usually be only exactly one default route, unless policy routing is used (and even then, only one default per table exists) Commented May 2, 2018 at 22:14
  • Adding the masquerade rule to eth1 fixed everything. I figured that the masquerade was letting the packets get forwarded, but since it's a postroute modification then it makes sense that packets were going through anyways. The multiple routes were because the interfaces were added one at a time and I wanted to make sure that removing one would leave network access for the virtual machine. Can you add your information to an answer so I can accept it? Commented May 3, 2018 at 12:29

1 Answer 1

Reset to default
1

The routes are applied in order. So the default route (as well as the example given to 172.18.221.227) is going through eth1 because it's first in the routing table. The only MASQUERADE rule is applied to packets going through eth0. As OP commented, there's no way an alteration in POSTROUTING could have altered the route. So there's simply no alteration done to packets going throught eth1 which keep the original RFC1918 IP.

So changing the rules to also have a MASQUERADE applying to eth1 fixes it.

In case the INPUT policy is set (again?) to DROP, replicating the state... ESTABLISHED to also apply from eth1 should also be considered.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.