The Problem: Static LAN Behind Dynamic WAN
Many home and small office networks consist of a central router connected to an ISP that provides a dynamic IP address via DHCP or PPPoE. Inside this network, computers, servers, and IoT devices are assigned static private IP addresses (such as 192.168.1.x) for stability and ease of management. Without NAT, these private addresses are not routable on the public Internet. When a device on the LAN attempts to reach an external server like google.com, the packet is dropped because the return traffic has no valid public destination address.
This scenario is often discovered when running a traceroute from a LAN client. The trace fails or shows unreachable hops because the intermediate routers cannot route the private source IP back to the sender. The solution lies in configuring the Linux kernel’s Netfilter subsystem, specifically IPTables, to perform Source NAT (SNAT) or Masquerading on the gateway device.
Understanding Masquerading vs. SNAT
While both SNAT and Masquerading change the source IP address of outgoing packets, they behave differently regarding dynamic addresses. Standard SNAT requires you to specify a fixed source IP address. This works well if your WAN connection has a static public IP. However, most residential ISPs assign dynamic IPs that can change periodically. If you use standard SNAT with a hardcoded IP, your internet access will break whenever the ISP changes your address.
Masquerading is a specialized form of SNAT designed for dynamic connections. It automatically detects the current IP address of the outgoing interface at the time each packet is sent. This makes it the correct choice for static LANs behind dynamic WAN setups. For a deeper understanding of how this mechanism works under the hood, you should review Understanding NAT Masquerading in iptables: A Comprehensive Guide. It explains the connection tracking table which ensures that reply packets from the internet are correctly mapped back to the original internal request.
Identifying Your Network Interfaces
Before applying any rules, you must identify which network interface connects to your local network (LAN) and which connects to the internet (WAN). On a typical Linux gateway, the LAN interface might be eth0 or br0 (if bridging), while the WAN interface could be ppp0, eth1, or pppoe-wan.
You can list all active interfaces and their configurations using the following command:
ip addr show
Look for the interface that holds your private subnet (e.g., 192.168.1.1/24). This is your -o (outbound) interface for the NAT rule. The other interface, which receives the public IP via DHCP or PPPoE, is where the traffic exits to the world. Note that interface names may vary depending on your distribution and hardware, so always verify them before proceeding.
Configuring the IPTables Rule
The core configuration involves adding a rule to the POSTROUTING chain of the nat table. This chain processes packets after routing decisions have been made, just before they leave the system. The command below enables masquerading for all traffic originating from the LAN subnet exiting through the WAN interface.
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
In this example, replace ppp0 with your actual WAN interface name. The -t nat flag specifies the table, -A POSTROUTING appends the rule to the end of the chain, -o ppp0 restricts the rule to the outbound interface, and -j MASQUERADE sets the target action. This single line allows all devices on the static LAN to share the dynamic WAN IP.
If you have more complex requirements, such as allowing specific services from the internet to reach internal servers, you might need additional rules. However, for basic internet access, the masquerade rule is sufficient. For cases involving multi-device connections like OrangePi clusters, see IPTables NAT Configuration: Laptop to OrangePi1 to OrangePi2 for advanced bridging scenarios.
Enabling IP Forwarding
NAT alone is not enough; the Linux kernel must also be allowed to forward packets between interfaces. By default, many distributions disable IP forwarding for security reasons. You can check the current status by reading the sysctl parameter:
cat /proc/sys/net/ipv4/ip_forward
If the output is 0, forwarding is disabled. To enable it temporarily, run:
echo 1 > /proc/sys/net/ipv4/ip_forward
To make this change persistent across reboots, add or modify the following line in /etc/sysctl.conf:
net.ipv4.ip_forward = 1
Then apply the changes with sysctl -p. Without this setting, even with correct NAT rules, packets will not pass through the gateway.
Persisting Rules Across Reboots
IPTables rules stored in memory are lost when the system restarts. To ensure your NAT configuration survives a reboot, you need to save the current rules. The method depends on your distribution. On Debian-based systems, you can install iptables-persistent and run:
sudo netfilter-persistent save
On RHEL/CentOS systems, you might use iptables-save to write to /etc/sysconfig/iptables or manage services via firewalld if available. Always verify your rules are loaded after a reboot by running iptables -t nat -L -n -v to confirm the MASQUERADE target is present.
Frequently Asked Questions
Why does my internal server lose internet access after a reboot?
This usually happens because either IP forwarding was disabled again or the IPTables rules were not saved persistently. Ensure net.ipv4.ip_forward=1 is set in /etc/sysctl.conf and that your NAT rules are restored via your distribution’s persistence mechanism.
Can I use SNAT instead of Masquerade for better performance?
SNAT is slightly faster because it does not look up the interface IP for every packet, but it only works if your WAN IP is static. Since your scenario involves a dynamic WAN, Masquerade is required despite the minor overhead, as it handles IP changes automatically.
How do I allow incoming SSH to a specific LAN device?
You need an additional rule in the INPUT or FORWARD chain. For example: iptables -A FORWARD -i ppp0 -o eth0 -p tcp --dport 22 -j ACCEPT. This must be combined with proper firewall policies to prevent unauthorized access to other ports.
What if my ISP uses CGNAT?
If your WAN interface itself has a private IP address due to Carrier-Grade NAT, standard IPTables NAT will not provide true public internet access. In this case, you would need IPv6 support or a tunnel broker, as traditional SNAT/MASQUERADE cannot bridge two layers of private addressing.
Does this setup affect VPN clients connecting to the LAN?
Yes, if VPN clients connect through the same WAN interface, their traffic will also be masqueraded. Ensure your VPN software creates appropriate routes or uses split tunneling if you want certain traffic to bypass the NAT gateway or follow different paths.