Routing traffic from LAN to WAN

Question

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.

Answer 1

I've found the problem

So the solution to my specific problem turned out to be quite simple. Either I overlooked it in other forum posts, or I simply didn't find any posts with this suggestion. The iptables rules are all fine, however I was missing the following command:

echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp

Executing this command immediately fixed the issue and now all is well.

Nevertheless thanks to everyone who commented!