VMware ESXi and vSphere Cluster Management

Configure IP Forwarding on Linux

Learn to enable IPv4 forwarding on Linux, configure routes and firewall rules, use NAT when needed, and verify a Linux host as a router.

IP forwarding is the Linux kernel behavior that receives an IP packet on one network interface and sends it onward through another interface according to the routing table. A normal host mainly processes packets addressed to itself. A router also forwards packets destined for other networks.

A common design uses a dual-homed Linux system: one interface connects to a LAN and another connects to a second LAN or an upstream WAN. For example, the Linux router might connect 192.168.10.0/24 through one interface and 192.168.20.0/24 through another.

Requirements for Using Linux as a Router

• The system needs at least two reachable network paths, usually two network interfaces. Separate paths can also be provided through VLANs, bridges, or other virtual networking designs.
• Each connected network needs valid IP addressing and an appropriate route.
• Client systems must use the Linux router as their default gateway, or have a more-specific route pointing remote networks to it.
• The firewall must permit the intended transit traffic.
• Remote networks must have a reverse path back to the originating network, unless suitable source NAT is used.

Forwarding is therefore only one component of routing. A useful mental model is:

1. The client sends a packet to its gateway.
2. The Linux host looks up the destination in its routing table.
3. The forwarding firewall evaluates the packet.
4. The kernel sends the packet through the selected output interface.
5. The destination sends a reply using a valid return route.

Check the Current IPv4 Forwarding Status

The sysctl interface displays and changes kernel parameters. The parameter net.ipv4.ip_forward controls IPv4 forwarding.

sysctl net.ipv4.ip_forward

A result ending in = 0 means forwarding is disabled. A result ending in = 1 means it is enabled. You can also read the active runtime value directly from procfs:

cat /proc/sys/net/ipv4/ip_forward

These commands inspect the value currently used by the running kernel. They do not tell you whether the value came from /etc/sysctl.conf, a file in /etc/sysctl.d/, or a temporary command.

Enable IPv4 Forwarding Temporarily

To enable forwarding immediately for the current runtime session, run:

sudo sysctl -w net.ipv4.ip_forward=1

The change takes effect immediately, so it is useful for testing or for applying an emergency runtime change. It normally does not survive a reboot. Persistent configuration must also be created if the router should retain this behavior.

Enable IPv4 Forwarding Persistently

Linux loads persistent sysctl values from configuration files. The traditional file is /etc/sysctl.conf. Add or enable this line:

net.ipv4.ip_forward = 1

A modular configuration file under /etc/sysctl.d/ is often easier to maintain. For example, create /etc/sysctl.d/99-ip-forwarding.conf containing:

net.ipv4.ip_forward = 1

Apply the traditional file with:

sudo sysctl -p /etc/sysctl.conf

Apply the system's configured sysctl files with:

sudo sysctl --system

After applying the configuration, verify the active value:

sysctl net.ipv4.ip_forward

When diagnosing unexpected values, look for duplicate definitions. A later-loaded file can override an earlier setting. Search the relevant configuration directories, review every occurrence of net.ipv4.ip_forward, remove conflicting entries, and then apply the configuration again.

Rebooting is a final persistence test, not a substitute for checking the active value. After the reboot, run sysctl net.ipv4.ip_forward again.

Configure the Routing Table

The routing table is the set of rules used to select an output interface and, when necessary, a next-hop router for a destination. Enabling forwarding permits the kernel to forward packets, but it does not create missing routes.

View interface addresses and states with:

ip addr show

View the IPv4 routing table with:

ip route show

Connected routes describe networks directly attached to local interfaces. A default route is used when no more-specific route matches; its next hop is the default gateway. A static route is a manually configured route to a particular network or host.

For example, this illustrative command adds a temporary route to a remote subnet through a next hop:

sudo ip route add 192.168.20.0/24 via <next-hop-ip> dev <interface>

Use route lookup to see how Linux will reach a destination:

ip route get <destination-ip>

The route above is temporary on many systems. Use the distribution's network management system to make static routes persistent.

Return-Path Routing

Routing must work in both directions. If a client on 192.168.10.0/24 sends through the Linux router to 192.168.20.0/24, the destination network must know how to send replies back to 192.168.10.0/24. That reverse path can be a route through the Linux router, a default gateway that already knows the route, or source NAT when routing the private source network upstream is not possible.

Firewall Policy for Forwarded Traffic

A firewall can block transit packets even when IPv4 forwarding is enabled. Traffic addressed to the Linux host itself follows local-input policy. Traffic passing through the host follows the firewall's forward chain or equivalent forwarding policy.

Permit forwarding only between the intended input and output interfaces and restrict it to the required source networks, destination networks, protocols, and ports. A typical stateful policy allows new connections from an approved internal network toward an approved external or remote network, then allows established and related return traffic. Stateful firewalling recognizes connection state so valid replies can return without opening unrelated new traffic.

Firewall commands differ by distribution and administration tool. Common choices include nftables, iptables compatibility rules, firewalld, and UFW. Do not assume that changing one tool updates another tool's policy. Inspect the active firewall configuration and make the forwarding decision in the tool that actually controls the host.

NAT and Internet Sharing

NAT, or Network Address Translation, changes address information in packets. Masquerading is a form of source NAT commonly used when the outbound interface has a dynamic address.

Source NAT or masquerading is typically needed when a private LAN accesses an upstream network that has no route back to the private subnet. The Linux router then translates the private source address to an address associated with its outbound or uplink interface. The upstream network replies to that translated address, and the router maps the reply back to the internal client.

NAT is not required when both networks are routed correctly and have bidirectional routes. In that design, hosts can retain their original addresses and the routers know how to reach both subnets.

Configure NAT separately from IP forwarding. Also configure the corresponding forwarding firewall policy and stateful return allowance. NAT can hide a missing route, but it should not replace proper routing when you control all participating networks.

Testing and Verification

1. Verify the active setting with sysctl net.ipv4.ip_forward.
2. Check interface addresses with ip addr show. Confirm both interfaces are up and have addresses in the expected subnets.
3. Check the routing table with ip route show. Confirm connected routes, a suitable default route where required, and static routes to remote networks.
4. From a client, ping or otherwise reach the Linux router's address on the client-facing network.
5. From that client, test a destination on the other network. Test by IP address before testing a hostname so DNS problems do not obscure routing problems.
6. Use ip route get <destination-ip> on the router to confirm route selection.
7. Use traceroute or tracepath to observe the gateway path and identify where replies stop.
8. Capture traffic on both router interfaces when necessary:

sudo tcpdump -ni <interface> host <client-or-destination-ip>

A packet seen on the incoming interface but not the outgoing interface suggests a route, firewall, or local processing problem. A packet seen leaving but no reply returning points toward the destination route, upstream firewall, NAT requirement, or return filtering. Always test return connectivity, not only whether one-way packets arrive.

Practical Network Scenarios

Route Between Two Private LANs

Suppose one Linux interface connects to 192.168.10.0/24 and another connects to 192.168.20.0/24. Enable forwarding, ensure the Linux host has an address on each subnet, and verify the connected routes. Configure clients to use the Linux router as their gateway or add a route to the opposite subnet. Permit forwarding between the two LAN interfaces. NAT is not needed when both LANs have correct routes back to one another.

Share an Internet Uplink with a Private LAN

Suppose the LAN is 192.168.50.0/24 and the Linux host has a separate WAN interface. Enable forwarding, allow LAN-to-WAN traffic, and permit established and related replies. If the upstream router has no route to 192.168.50.0/24, configure outbound masquerading on the WAN interface. Give LAN clients the Linux host as their gateway and configure DNS separately.

Troubleshooting Common Failures

The Value Returns to 0

A runtime-only change disappears after reboot. A persistent file may also have been edited without being applied, or a later sysctl file may override it. Check the active value, search sysctl configuration files for all definitions of net.ipv4.ip_forward, keep the intended persistent value, and run sudo sysctl --system.

Clients Reach the Router but Not the Remote Network

Inspect ip route show on the router and the client. Confirm that the client uses the Linux host as its gateway or has a route to the remote subnet. Then review the firewall's forwarding policy and verify that the interface directions are correct.

The Destination Receives Traffic but Replies Do Not Return

Check the remote network's gateway and return route. If the upstream network cannot route back to the source subnet, determine whether source NAT is appropriate. Also verify that the firewall allows established and related return traffic.

Forwarding Works but Internet Access Fails

Test a public IP address before testing a hostname. If IP connectivity works but names do not, investigate client DNS separately. If IP connectivity fails, check whether the upstream router has a route to the private subnet and whether outbound masquerading is required and correctly applied.

IPv6 Forwarding Is Separate

IPv4 and IPv6 forwarding are independently configured. The related IPv6 kernel parameter is:

sysctl net.ipv6.conf.all.forwarding

Enabling net.ipv4.ip_forward does not enable IPv6 forwarding. IPv6 also requires separate routes and firewall policy, and router advertisements can affect how hosts select gateways and configure addresses. Design and test IPv6 routing independently from IPv4.

Security and Operational Considerations

• Enable forwarding only on systems intentionally used to route traffic.
• Limit forwarding rules to required source networks, destinations, protocols, and interfaces.
• Avoid unintentionally exposing SSH, web administration, and other management services on router-facing interfaces.
• Document interface names, addresses, routes, firewall policy, and NAT behavior.
• Record whether NAT is being used because of a deliberate design choice or because a required return route is missing.
• After changes, verify both directions of communication and test behavior after reboot.