Verify the Routing Table
The first step in troubleshooting any network issue is confirming that the operating system knows where to send traffic. On Linux Server 2, you must ensure that the default route explicitly points to the IP address of Linux Gateway. If this route is missing or incorrect, all outbound traffic will be dropped or sent to the wrong interface.
Run the following command to inspect the current routing table:
ip route showYou should see a line similar to default via <Gateway_IP> dev eth0. If this line is absent, your server does not know how to exit its local subnet. You can temporarily add it using ip route add default via <Gateway_IP>, but this change will vanish after a reboot. To make it permanent, you need to edit your network configuration file, typically located in /etc/network/interfaces or /etc/netplan/ depending on your distribution. Ensure the gateway address matches the internal IP of Linux Gateway exactly.
Check NAT Configuration on Linux Gateway
Even if Linux Server 2 has the correct route, it cannot access the internet unless Linux Gateway translates private IP addresses to a public one. This process is called Masquerading. Without it, return traffic from the internet will not know which internal server to reply to.
Log into Linux Gateway and check if the MASQUERADE rule exists in the nat table of iptables:
iptables -t nat -L -n -vLook for a rule in the POSTROUTING chain that specifies MASQUERADE for the source network of Linux Server 2. If this rule is missing, add it by replacing variables with your actual subnet details:
iptables -t nat -A POSTROUTING -s <Server_2_Subnet> -o <Public_Interface> -j MASQUERADEThis command tells the kernel to rewrite the source IP of outgoing packets from Server 2 to the public IP of the gateway’s external interface. Remember that iptables rules are volatile; they disappear on reboot. You must save them using your distribution’s service manager, such as netfilter-persistent save on Debian or enabling the iptables-services unit on RHEL-based systems.
Test Connectivity and DNS Resolution
Once routing and NAT are confirmed, test basic connectivity. Use ping to target an external IP address, such as 8.8.8.8. If ping succeeds, the layer 3 path is functional. However, many users confuse DNS failures with total internet outages. If ping 8.8.8.8 works but ping google.com fails, the issue is DNS resolution, not routing.
Check the contents of /etc/resolv.conf on Linux Server 2. It should point to a valid nameserver, often the gateway itself or a public DNS like 1.1.1.1. If the file is empty or points to a non-functional resolver, update it manually or configure your DHCP client to push the correct DNS settings. For persistent changes, consider configuring systemd-resolved or editing the network manager profiles directly rather than modifying resolv.conf by hand, as it may be overwritten.
Inspect Firewall Rules on the Gateway
Sometimes, NAT is configured correctly, but the firewall on Linux Gateway blocks forwarded traffic. Check the forward chain in the filter table:
iptables -L FORWARD -n -vIf you see a policy of DROP or REJECT without an explicit ACCEPT rule for the forwarded traffic between the internal and external interfaces, packets will be silently discarded. Add a rule to accept established connections and new forwarding traffic:
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s <Server_2_Subnet> -o <Public_Interface> -j ACCEPTThis ensures that while the gateway protects its own services, it allows data to flow through it for clients like Server 2.
Related Troubleshooting Resources
If you suspect the issue involves encrypted tunnels rather than standard routing, consult these specific guides:
- Troubleshooting WireGuard Client-to-Client Communication Issues covers peer-to-peer connectivity problems that might mimic routing errors.
- Troubleshooting: Cannot Connect to the Internet provides deeper insights into DNS-specific failures when basic pings fail.
Frequently Asked Questions
Why can I ping the gateway but not the internet?
This indicates that Layer 2 and Layer 3 connectivity to the gateway is fine, but the gateway is not translating or forwarding the packets. Verify that the MASQUERADE rule exists in the NAT table and that the FORWARD chain allows traffic from the server’s subnet to exit via the public interface.
How do I make iptables rules persistent across reboots?
On Debian-based systems, use apt install iptables-persistent and then run netfilter-persistent save. On RHEL/CentOS, enable the iptables-services package and run systemctl enable iptables to ensure rules load at boot time automatically.
What if /etc/resolv.conf keeps getting overwritten?
Modern Linux distributions often use systemd-resolved or NetworkManager to manage DNS dynamically. Instead of editing resolv.conf directly, configure your DNS servers within the network connection profile or use the resolvectl command to set static upstream resolvers for specific domains.
Can I use iproute2 instead of iptables for NAT?
No, iproute2 is strictly for routing and link management. NAT requires packet mangling which is handled by the netfilter subsystem via iptables, nftables, or firewalld. You must use one of these tools to perform Masquerading.
How do I check if the gateway is actually connected to the internet?
SSH into Linux Gateway and run ping 8.8.8.8 or curl http://example.com. If the gateway itself cannot reach the internet, the problem is upstream (ISP or router), not the configuration between Server 2 and the gateway.