I am trying to understand ARP behavior that I have observed in the following scenario. This isn’t a troubleshooting question as there is no problem, I am just trying to understand how/why this behavior occurs.
Scenario (refer to attached jpeg),
eth1 interface does not have a DHCP address (this is ok)
client 1 (192.168.0.254) attempts to ping 10.0.0.100
An ARP request packet capture between eth1 and server1 shows the following
Sending IP Address: 192.168.0.1
Target IP Address: 10.0.0.100
Other configuration
Firewall
NAT Rule
General
Chain: srcnat
Out.Interface: eth1
Action
Action: masquerade
This question is more for me to understand how ARP functions in this scenario and what options exists to stop ARP from propagating into the WAN side when eth1 does not have a IPv4 address.
The layer 3 IP has no concept of MAC addresses, IP firewall and routing are irrelevant to ARP. ARP works within a layer 2 broadcast domain to provide the MAC address associated with an IP address - it doesn’t get forwarded outside the broadcast domain.
To get better idea about what’s going on you may want to fire up wireshark on client and capture all communication. But in a nutshell it’s like this:
client has IP address 192.168.0.254, netmask /24 and gateway 192.168.0.1.
Let’s assume there are no specific routing rules on client.
similarly server has IP address of 10.0.0.100, netmask /24 and gateway 10.0.0.1.
Let’s assume similarly to client that server doesn’t have any specific routing rules.
when client wants to connect to 10.0.0.100, it figures that target is outside own subnet and it thus has to send traffic to its gateway
client uses ARP (“who has” in particular) to discover MAC address of gateway … gateway replies with its own MAC address (correct for interface where it has IP 192.168.0.1 bound)
client sends packets with destination IP address 10.0.0.100 to gateway’s MAC address
gateway receives those packets (because they are targeting it’s MAC address), inspects destination IP address, notices it doesn’t match any of its own addresses, looks up routing tables and notices new egress interface
gateway uses ARP (“who has”) to discover MAC address of server
gateway sends packets with same IP headers and payload but with changed ethernet headers (destination MAC is server’s MAC, source MAC is gateway’s MAC)
… similarly in the opposite direction
If you introduce NAT on the gateway, in principle gateway would still need IP addresses on its interfaces, but would perform NAT … so client (in step 3) would try to connect to gateway’s IP address, it would still ask for MAC address in step 4 but for the “destination IP address” not for gateway, gateway would reply with its own MAC address never the less. In step 5 client sends IP packet to gateways MAC address and destination IP address set to gateway’s IP address. In step 6 gateway receives IP packet, finds out it’s destined to one of its own IP addresses, figures it needs to perform NAT, does it and then proceeds with steps 7 and 8. In opposite direction the difference is similar to described before, the NAT is inverse.
So when I’m inside the thought box I described above I don’t get the “does not have a DHCP address” for one of gateway’s interfaces. In principle it means that NAT has to be hard-coded with new dst address … but ARP from server’s side wouldn’t work as the gateway’s IP stack (the one replying to ARP requests) wouldn’t know what to answer.
