Enable IP Forwarding on Linux

Learn how to enable IPv4 forwarding on Linux temporarily or persistently, configure routing, firewall rules, NAT, IPv6 forwarding, and safely test a Linux router.

IP forwarding is the Linux kernel behavior that passes packets received on one network interface to another interface. When a Linux host has connectivity to multiple IP networks, enabling forwarding allows it to operate as a router.

Without forwarding, Linux normally delivers packets addressed to the local system or discards packets that are not meant for it. With forwarding enabled, the kernel consults its routing table, selects an outgoing interface and next hop, and transmits packets destined for another host or network.

When Linux IP forwarding is needed

Connecting two distinct LANs through one Linux machine.
Using Linux as the gateway for a private network.
Routing traffic between virtual-machine, container, VPN, or tunnel networks.
Providing access from a private subnet to an external network.

Forwarding alone does not provide internet access. Clients need a usable route to the Linux gateway, the Linux host needs an outbound route, firewall rules must allow the traffic, and the upstream network must either have a return route or be compatible with source NAT.

Example topology: two private LANs

In this example, the Linux router has one interface in 192.168.10.0/24 and another in 192.168.20.0/24.

LAN A: 192.168.10.0/24                    LAN B: 192.168.20.0/24
Host A                         Linux router                         Host B
192.168.10.50 ---- eth0 192.168.10.1 | 192.168.20.1 eth1 ---- 192.168.20.50
                         <----- forward packet ----->
                         <----- return packet  ----->

Hosts in LAN A can use 192.168.10.1 as their gateway for LAN B. Hosts in LAN B can use 192.168.20.1 as their gateway for LAN A. Alternatively, existing routers can contain specific routes through the Linux system.

Check the current IPv4 forwarding state

The sysctl command views and changes Linux kernel parameters. The IPv4 forwarding parameter is net.ipv4.ip_forward.

sysctl net.ipv4.ip_forward

A typical result is:

net.ipv4.ip_forward = 0

The equivalent active value is exposed through procfs:

cat /proc/sys/net/ipv4/ip_forward

0 means IPv4 forwarding is disabled.
1 means IPv4 forwarding is enabled.

Enable IPv4 forwarding temporarily

To enable forwarding immediately for the running system, use:

sudo sysctl -w net.ipv4.ip_forward=1

A runtime sysctl change takes effect immediately. It is useful for testing a topology before making a permanent change. The setting may be lost after reboot, or replaced when system configuration is reloaded.

Verify the effective value:

sysctl net.ipv4.ip_forward
cat /proc/sys/net/ipv4/ip_forward

A direct procfs write is another runtime method:

echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward

The sysctl command is generally clearer because it identifies the named kernel parameter and works naturally with persistent sysctl configuration.

Enable IPv4 forwarding persistently

Persistent kernel parameters are commonly stored in /etc/sysctl.conf or in a file under /etc/sysctl.d/. Add this setting:

net.ipv4.ip_forward = 1

Option 1: Use /etc/sysctl.conf

Edit the file with an administrative editor and add the parameter:

sudo editor /etc/sysctl.conf

Apply that file without restarting:

sudo sysctl -p /etc/sysctl.conf

Option 2: Use a dedicated sysctl.d file

A dedicated file keeps your local change separate from the main configuration file. The high numeric prefix helps the file load late relative to many other files:

printf '%s\n' 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-ip-forwarding.conf

Load settings from the standard configuration locations:

sudo sysctl --system

Then verify the effective value:

sysctl net.ipv4.ip_forward

Use either /etc/sysctl.conf or a dedicated file for the setting, not multiple conflicting definitions. If a later file overrides an earlier one, the final loaded value is the one that controls the kernel.

IPv4 forwarding configuration methods

Method	Setting or file	Takes effect	Survives reboot	Best use
Runtime sysctl command	`sysctl -w net.ipv4.ip_forward=1`	Immediately	No	Testing or temporary operation
Direct procfs write	`/proc/sys/net/ipv4/ip_forward`	Immediately	No	Low-level temporary change
Primary configuration	`/etc/sysctl.conf`	When loaded or at boot	Yes	Simple system-wide configuration
Dedicated configuration	`/etc/sysctl.d/99-ip-forwarding.conf`	When loaded or at boot	Yes	Organized local or role-specific configuration

Routing requirements beyond the kernel setting

The kernel can forward a packet only when the network topology supplies valid addressing and routes.

Requirement	Why it matters	How to verify
Forwarding enabled	Permits the kernel to route IPv4 packets between interfaces.	`sysctl net.ipv4.ip_forward`
Correct interface addresses	Each interface must belong to the intended network.	`ip addr`
Routes exist in both directions	The router must know each destination, and replies must know the reverse path.	`ip route` on relevant systems
Clients use the correct gateway	Packets for remote networks must be sent to the Linux router or another router with a route through it.	Inspect client routes and default gateway
Firewall permits forwarded traffic	A firewall can drop packets even when kernel forwarding is enabled.	Inspect the active firewall framework and counters
NAT when required	External networks may not know how to return traffic to private addresses.	Inspect source NAT or masquerade rules

Addressing and routes

Use non-overlapping subnets on separate routed interfaces. For example, 192.168.10.0/24 and 192.168.20.0/24 are distinct, while placing both interfaces in the same subnet can create ambiguous routing and address-resolution behavior.

Inspect the Linux host:

ip addr
ip route

A client on a private LAN needs either a route such as 192.168.20.0/24 via 192.168.10.1 or a default gateway of 192.168.10.1. The destination-side network needs a route back to the source network. This reverse path is essential: a request can arrive successfully but still appear to fail if replies take an invalid or missing route.

Firewall forwarding policy

Forwarded packets pass through the firewall's forwarding path rather than being delivered locally. In iptables terminology, this is the FORWARD chain. A default drop policy can therefore block routed traffic while local access to the Linux router continues to work.

Permit only the traffic appropriate for your topology. A common policy for a gateway includes:

Allowing new connections from the trusted LAN toward the permitted uplink or destination network.
Allowing established and related return traffic.
Restricting unsolicited connections arriving from an untrusted uplink.
Logging or monitoring denied traffic where useful.

Linux systems may use nftables, iptables, firewalld, or ufw as the management layer. Syntax, default policies, rule ordering, and persistence vary by distribution and framework. Do not mix management layers casually; a manually added rule may be replaced by a service reload.

NAT and masquerading for private networks

NAT (network address translation) changes packet addressing while traffic crosses the router. Masquerading is a source-NAT form commonly used when the outbound interface address can change, such as on a dynamic uplink.

Suppose clients in 10.0.0.0/24 use a Linux gateway to reach the internet. If the upstream network has no route back to 10.0.0.0/24, replies cannot return directly. Source NAT or masquerading changes the apparent source to the gateway's uplink address, allowing the upstream network to return traffic to the gateway.

Feature	IP forwarding	NAT/masquerading
Primary purpose	Routes packets between interfaces and networks.	Translates source or destination addresses during transit.
Whether addresses change	Normally no.	Yes.
When required	Whenever the Linux host must route traffic between networks.	When the other network lacks a route back to private addresses, or when address translation is otherwise required.
Effect on return routing	Requires reciprocal routes.	Can avoid an upstream route to the translated private subnet, but still requires return traffic to reach the translated address.

NAT is not required when all networks have correct reciprocal routes. In the two-private-LAN example, routing without NAT usually preserves the original client addresses and is easier to troubleshoot.

IPv6 forwarding

IPv6 has a separate forwarding setting. Enabling IPv4 forwarding does not enable IPv6 forwarding.

sysctl net.ipv6.conf.all.forwarding

When IPv6 routing is required, a persistent setting can be added as follows:

net.ipv6.conf.all.forwarding = 1

IPv6 clients also need a usable IPv6 route, commonly supplied through router advertisements or another route-configuration method. Check IPv6 routes with:

ip -6 route

IPv6 firewall policy must independently permit the intended forwarded traffic.

Validation and safe testing

Confirm the forwarding value after applying configuration.
Inspect interface addresses with ip addr.
Inspect connected, static, and default routes with ip route.
Confirm that each client uses the intended default gateway or specific route.
Test from hosts on opposite networks with ping where permitted.
Use tracepath or traceroute to identify the hop where traffic stops.
Capture packets on both router interfaces with an appropriate packet-capture tool to determine whether traffic arrives, leaves, and returns.

Test in both directions. A successful ping to the router itself proves local connectivity, not forwarding. A successful request with no reply often indicates a missing reverse route, a firewall rule, or NAT behavior.

Troubleshooting common failures

Forwarding is enabled, but separate networks cannot communicate

Check ip route on the Linux router and affected clients.
Confirm client default gateways or specific routes.
Verify that the remote network has a route back to the source subnet.
Inspect firewall forwarding policy and rule counters.
Capture traffic on both router interfaces to see where packets stop.

Forwarding works until reboot

The change may have been made only with sysctl -w or a procfs write.
Check /etc/sysctl.conf and files under /etc/sysctl.d/.
Run sudo sysctl --system and review syntax errors.
Check whether a later configuration file overrides the desired value.

Private clients reach the gateway but not the internet

Test internet access directly from the Linux gateway.
Check that the gateway has a default route.
Confirm that LAN-to-uplink forwarding is allowed.
Determine whether source NAT or masquerading is needed.
Check DNS separately from raw IP connectivity.
Ask whether the upstream router has a route back to the private subnet.

Connectivity works in only one direction

Compare routes on both ends and inspect the reverse path.
Check whether stateful firewall rules permit established return traffic.
Inspect connection-tracking and firewall counters.
Review reverse-path filtering and policy routing when the topology is asymmetric.

IPv4 works but IPv6 does not

Check net.ipv6.conf.all.forwarding.
Inspect routes with ip -6 route.
Verify router advertisements or another method that provides clients with an IPv6 default route.
Inspect IPv6 firewall forwarding rules.

Practical workflow

Document the interfaces, subnets, gateways, and intended traffic flows.
Verify that the interface addresses and subnets do not overlap.
Enable IPv4 forwarding temporarily.
Configure or verify routes in both directions.
Apply the least-permissive firewall forwarding policy needed for testing.
Add NAT only if the external network lacks a return route or translation is otherwise required.
Test with route inspection, pings where allowed, tracepath or traceroute, and packet capture.
After successful testing, place the sysctl setting in the chosen persistent configuration file.
Reload and verify the setting, then document firewall and route persistence as well.

For related Linux command-line and system administration fundamentals, see Linux and File Structure In Linux.