Expert Tips for Forwarding Internet Traffic between Two Networks

To forward internet traffic between two networks using a server with IP 10.0.0.1/16, you must enable IP forwarding in the kernel and configure Network Address Translation (NAT) rules. This setup allows clients on isolated subnets to reach external resources through the central server acting as a gateway. The process involves modifying system parameters and defining iptables or nftables rules to masquerade outgoing packets.

Prerequisites and Network Topology

Before configuring the routing logic, ensure your server has two distinct network interfaces connected to the separate networks you wish to bridge. For example, one interface might connect to the internal LAN (e.g., eth0) and another to the upstream internet connection (e.g., eth1). The server itself holds the IP address 10.0.0.1 with a subnet mask of /16, meaning it serves as the default gateway for devices within that large private range. You need to verify that both interfaces are up and correctly assigned their respective IP addresses. If the second network is a different subnet entirely, the server must have an IP configured on that interface as well, even if it is not part of the 10.0.0.0/16 range. This dual-homed configuration is essential for routing traffic between disparate layers.

Enabling Kernel IP Forwarding

The Linux kernel does not route packets between interfaces by default for security reasons. You must explicitly enable this behavior. To do this permanently, edit the sysctl configuration file. Open /etc/sysctl.conf or create a new file in /etc/sysctl.d/ such as 99-ipforward.conf. Add the following line:

net.ipv4.ip_forward = 1

After saving the file, apply the changes immediately without rebooting by running:

sysctl -p

Verify that forwarding is active by checking the value:

cat /proc/sys/net/ipv4/ip_forward

This output should return 1. If it returns 0, the kernel will drop all forwarded packets, resulting in no connectivity for client devices.

Configuring NAT Rules

Simply forwarding packets is not enough; the destination servers on the internet will see packets coming from private IP ranges (like 10.x.x.x) and may reject them or fail to route replies correctly. You must use Source Network Address Translation (SNAT) or Masquerading to replace the source IP of outgoing packets with the server's public-facing interface IP. Using iptables, which is still widely supported, add the following rule to the POSTROUTING chain. Replace eth1 with your actual upstream interface name:

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

If you prefer using nftables, the equivalent command would be:

nft add rule ip nat postrouting oifname "eth1" masquerade

This rule ensures that any packet leaving via the internet interface gets its source address rewritten to the IP of that interface. This is critical for maintaining stateful connections.

DNS and DHCP Configuration

Clients on the remote networks need to know how to reach the gateway and how to resolve domain names. If you are managing DHCP services, ensure the gateway option points to the server's IP on that specific subnet. For example, if the internal network is 10.0.0.0/16, the DHCP scope should offer 10.0.0.1 as the router. Additionally, configure DNS servers in the DHCP options. Using public DNS like 8.8.8.8 or 1.1.1.1 is common, but you can also point to local caching DNS servers if they exist. Without correct DNS resolution, users will get "Server Not Found" errors even if routing works perfectly. For more insights on handling complex DHCP scenarios across VLANs, consider reading How to Configure a Gateway's DHCP and DNS to Resolve Hosts with the Same Hostname but Different VLAN Domains. This resource details best practices for avoiding namespace collisions in multi-subnet environments.

Firewall Considerations

While NAT handles the translation, you must also allow forwarding in the filter table. By default, many fireblocks deny all forwarded traffic. Ensure your INPUT and FORWARD chains permit necessary traffic. A basic rule to allow established connections and related traffic is:

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

You may also need to allow new incoming connections depending on your security policy. However, be cautious not to expose internal services directly. Restricting access to specific ports or source IPs adds a layer of security. If you are running virtualized environments like OpenVZ, additional steps are required to allow iptables rules to function correctly within containers. See How to configure iptables to allow OpenVPN clients to access internet via the server, if it's run under OpenVZ? for specific container-level adjustments.

Testing Connectivity

Once configured, test from a client machine on the remote network. Ping an external IP like 8.8.8.8 to verify basic routing. Then, try resolving a domain name to confirm DNS is working. Use traceroute to ensure packets are passing through the server correctly. If connectivity fails, check the server's routing table with ip route to ensure there is a default route pointing to the upstream ISP gateway. Also, review iptables -t nat -L -n -v to confirm the masquerade rule is active and counting packets.

Frequently Asked Questions

Why can't clients ping the internet after enabling IP forwarding?

This usually happens because NAT is not configured. IP forwarding only moves packets between interfaces; it does not change their source IP. Without MASQUERADE or SNAT, the internet sees private RFC1918 addresses and drops the response.

Is it safe to use a /16 subnet for internal networking?

A /16 subnet provides over 65,000 addresses, which is suitable for large enterprises. However, ensure your DHCP server is properly scoped to avoid exhaustion. Also, verify that no other network segments overlap with this range to prevent routing conflicts.

What if I use nftables instead of iptables?

nftables is the modern replacement for iptables and offers better performance and syntax. The logic remains identical: enable forwarding in sysctl and add a masquerade rule in the nat table's postrouting chain. Most modern distributions support nftables by default.

Can I block specific traffic while forwarding others?

Yes, you can insert DROP rules in the FORWARD chain before the ACCEPT rules. Order matters in firewall tables; place restrictive rules first. For example, block known malicious IPs or restrict access to sensitive internal ports from the external network.

Does this setup work for IPv6?

The steps above are for IPv4. For IPv6, you must enable net.ipv6.conf.all.forwarding and configure NAT66 or SLAAC appropriately. IPv6 often relies on stateless address autoconfiguration rather than traditional NAT, so the approach differs significantly.