We have a test setup where several components are connected to their own network. This network has the the following address: 172.25.1.0/24. Most, if not all, of the components have static IP addresses, as they are defined by several standards and documents.
Our company network is separated from this machine network for obvious reasons, yet for different testing scenarios, certain components from within the machine network must be able to communicate with the Internet.
For our setup, we have the machine network connected to a RaspberryPi 4 (8GiB) via a USB Ethernet adapter (10/100/1000T) and the built-in network adapter connected to the company network with access to WAN.
The idea is, that the Pi masquerades the traffic coming from 172.25.1.0/24 to <anywhere>.
The setup has worked for quite a long time, but recently it has simply stopped routing the traffic. I'm at a loss as to why.
We have a script that sets up the iptables rules and this has previously worked up until the weekend (this past weekend):
#!/bin/bash IPTABLES=/sbin/iptables WANIF='eth0' LANIF='eth1' # enable ip forwarding in the kernel echo 'Enabling Kernel IP forwarding...' /bin/echo 1 > /proc/sys/net/ipv4/ip_forward # flush rules and delete chains echo 'Flushing rules and deleting existing chains...' $IPTABLES -F $IPTABLES -X # enable masquerading to allow LAN internet access echo 'Enabling IP Masquerading and other rules...' $IPTABLES -t nat -A POSTROUTING -o $LANIF -j MASQUERADE $IPTABLES -A FORWARD -i $LANIF -o $WANIF -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT $IPTABLES -A FORWARD -i $WANIF -o $LANIF -j ACCEPT $IPTABLES -t nat -A POSTROUTING -o $WANIF -j MASQUERADE $IPTABLES -A FORWARD -i $WANIF -o $LANIF -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT $IPTABLES -A FORWARD -i $LANIF -o $WANIF -j ACCEPT $IPTABLES -A INPUT -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT echo 'Done.'
The resulting iptables rules look like this:
Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate NEW,RELATED,ESTABLISHED Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere state NEW,RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere state NEW,RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination
As far as I can tell, this should route all the traffic from eth1 (LAN) to eth0 (WAN) - which is exactly what it has previously done. Yet evidently, when I try to ping Google's DNS, I get the following:
ping -I eth0 126.96.36.199 PING 188.8.131.52 (184.108.40.206): 56 data bytes ^C --- 220.127.116.11 ping statistics --- 1317 packets transmitted, 0 packets received, 100% packet loss
Any help on the matter would be much appreciated. Without packet forwarding/masquerading, our most critical tests can't run. Thanks!
As per request the output of
0.0.0.0/24 via 10.0.101.1 dev eth0 default via 10.0.101.1 dev eth0 10.0.101.0/24 dev eth0 proto kernel scope link src 10.0.101.160 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 172.25.1.0/24 dev eth1 proto kernel scope link src 172.25.1.160
Edit: the second
The RasPi has the following IPs on its interfaces: eth0 = 10.0.101.160 eth1 = 172.25.1.160
Pings: Pinging 172.25.1.160 works as expected. Avg. ping time is 0.5ms.
Pinging the outgoing interface of the Pi (10.0.101.160) also works. Avg. ping time is 0.667ms.
This means that I can assume some of the traffic at least makes it to the interface and back to the LAN. However, I still do not see why the traffic isn't leaving the interface to the "WAN" (company network). Running tcpdump -i eth1 shows that when pinging clients in the company network, ARP requests arrive at the interface:
13:12:39.660173 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.25.1.57 tell 172.25.1.3, length 46 2 packets captured 492 packets received by filter 484 packets dropped by kernel
Calling tcpdump on eth0, however, does not yield any messages from eth1. To me this indicates the problem is with the iptables rules, which have previously worked, but that is no longer the case; meaning I'm back at my original question.