IP addresses alone cannot transmit data within a LAN. To deliver data over Ethernet, physical addresses (MAC addresses) are required, and the protocol that resolves this is ARP (Address Resolution Protocol).
1. ARP Basics
When communicating with devices on the same LAN (subnet), the source queries the entire LAN for the MAC address associated with a specified IP address (ARP Request / Broadcast).
Only the node holding that IP address responds directly with its own MAC address (ARP Reply / Unicast).
2. Communication Flow: From Source PC to Destination Server
Here is how the MAC addresses and IP addresses in packet headers change during cross-internet communication.
Preconditions (Address Settings)
- Source PC: IP
192.168.1.10/ MACAA:AA:AA - Local Router (LAN side): IP
192.168.1.1/ MACBB:BB:BB - Local Router (WAN side): IP
203.0.113.1/ MACCC:CC:CC - Remote Router (WAN side): IP
198.51.100.1/ MACDD:DD:DD - Remote Router (LAN side): IP
10.0.0.1/ MACEE:EE:EE - Destination Web Server: IP
10.0.0.100/ MACFF:FF:FF
Step-by-Step Operation
- Subnet Determination (Source PC):
Recognizes that the destination IP (10.0.0.100) is outside the local LAN and decides to send to the default gateway (192.168.1.1). - ARP on Local LAN (Source PC):
Sends an ARP request (broadcast) on the local LAN to get the router’s MAC: “Request MAC for192.168.1.1” → Router replies withBB:BB:BB. - Packet Transmission (PC → Local Router):
Sends packet with Destination IP:10.0.0.100/ Destination MAC:BB:BB:BB(Router). - Routing & MAC Rewriting (Local Router):
Keeps the destination IP (10.0.0.100) fixed, rewrites the destination MAC to the next router’s MAC, and sets the source MAC toCC:CC:CCbefore forwarding. - ARP on Remote LAN (Remote Router):
The remote router receives the data. To get the MAC for10.0.0.100within its local LAN (10.0.0.0/24), it executes a new ARP broadcast on the remote LAN and acquires the server’s MAC (FF:FF:FF). - Server Arrival (Remote Router → Server):
Rewrites Destination IP:10.0.0.100/ Destination MAC:FF:FF:FFfor final delivery.
3. Question: Isn’t “192.168.x.x” Standard for LANs? Why Use “10.0.0.100” for the Server?
While home routers typically use “LAN = 192.168.x.x“, there is a clear reason for setting the destination server to 10.0.0.100 in the example above. If both LANs use the same 192.168.1.x subnet, communication issues occur.
If the destination IP shares the same network prefix as its own, a PC assumes the destination is within the local LAN and attempts to find it directly via ARP instead of forwarding traffic through the router.
Concrete Example of IP Conflict Communication Issues
- Suppose you connect via VPN to your home or office LAN (
192.168.1.x) from a cafe Wi-Fi network that also uses192.168.1.x. - When attempting to communicate with a target IP (e.g.,
192.168.1.50), your PC mistakenly assumes the target device exists inside the cafe’s Wi-Fi network. - As a result, packets are never sent through the VPN tunnel, resulting in ARP requests timing out on the local cafe LAN.
Standard Practices for Avoiding Conflict Issues
- Standard Network Design: To avoid overlaps with widely used home networks (
192.168.0.xor192.168.1.x), servers and corporate LANs standardly adopt10.x.x.xor172.16.x.xsubnets. - Home NAS Setups & Virtual VPNs: When setting up a home NAS for remote access, using the default
192.168.x.xsubnet leads to IP conflicts over VPN connections. While reconfiguring the home subnet is a fundamental fix, many feel uncomfortable when a home network isn’t192.168.x.x. Introducing a virtual mesh VPN service like Tailscale (which uses100.64.0.0/10virtual IPs) seamlessly resolves physical IP conflicts without altering home network settings.
Summary
Network communication relies on Layer 3 (IP) for final destinations and Layer 2 (MAC/ARP) for next-hop node delivery.
Understanding IP address range design is essential for preventing connectivity issues in VPN setups and local development environments like Docker.