Preamble
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.
Setup
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.
IP Rules
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 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 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!
Edit
As per request the output of ip route
:
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.
ping
along all addresses on the route to get a better idea of where it breaks.