How to Set Up Fedora as a Router or Gateway

A Fedora machine with two network interfaces can act as a router or NAT gateway by enabling IP forwarding and configuring firewalld masquerading.

You have a Fedora machine with two network cards. One connects to your modem, the other to a switch for your home lab or office. You want this box to route traffic between them, hide your internal IPs, and hand out DHCP addresses. You tried enabling forwarding, but the internet still won't work from the LAN side. The packets are dropping silently.

What is actually happening

A Linux router performs three distinct jobs. The kernel moves packets from one interface to another. The firewall decides which packets are allowed to cross. Network Address Translation rewrites the source IP so the upstream provider sees only one public address. Fedora handles this with sysctl for forwarding, firewalld for zones and NAT, and NetworkManager for interface configuration. The default Fedora install blocks forwarding and drops forwarded packets. You need to open the gates and tell the firewall how to translate addresses.

Think of the router as a mailroom clerk. The clerk takes a letter from the internal office, stamps the building's return address on the envelope, and hands it to the postal service. When a reply comes, the clerk checks the tracking number, removes the building's stamp, and delivers it to the correct desk. The kernel is the clerk's hands moving the mail. The firewall is the clerk checking the address list. NAT is the stamp that hides the internal office details from the outside world.

Identify your interfaces

You need to know the exact names of your network interfaces. Fedora uses predictable network interface names based on hardware topology. The names look like enp1s0 or eth0. You must use the correct names in every subsequent command. A mismatch creates a configuration that never applies.

Here is how to list all interfaces and confirm they are detected by the kernel.

ip link show
# Lists all network interfaces with their state and MAC addresses.
# Look for 'state UP' to confirm the cable is detected and the link is active.
# Note the interface names for the WAN and LAN ports.

Verify interface names before configuring. A typo in the interface name creates a profile that never activates.

Assign the LAN interface a static IP

The router's LAN interface needs a fixed IP address so clients can always find the gateway. NetworkManager manages this via connection profiles. Profiles persist across reboots and handle activation automatically. You must ensure the LAN profile does not set a default gateway. A gateway on the LAN side creates a routing conflict that breaks outbound traffic.

Here is how to create a persistent static IP profile for the LAN interface without a gateway.

sudo nmcli con add type ethernet ifname enp2s0 con-name lan-static \
  ipv4.method manual ipv4.addresses 192.168.100.1/24 \
  ipv4.gateway "" connection.autoconnect yes
# Creates a persistent connection profile for the LAN interface.
# ipv4.method manual disables DHCP client on this interface.
# ipv4.gateway "" prevents NetworkManager from adding a default route on the LAN side.
sudo nmcli con up lan-static
# Activates the profile immediately without rebooting.
# NetworkManager applies the IP address and brings the interface up.

Leave the gateway empty on the LAN interface. Setting a gateway on the internal side creates a routing conflict that breaks outbound traffic.

Enable IP forwarding

The Linux kernel drops packets destined for other interfaces by default. You must enable the ip_forward sysctl parameter to allow the kernel to route traffic. The change needs to happen in the running kernel immediately and persist in a configuration file for reboots.

Here is how to enable forwarding now and make it survive reboots.

sudo sysctl -w net.ipv4.ip_forward=1
# Enables packet forwarding in the running kernel immediately.
# Without this, the kernel drops packets destined for other interfaces.
echo "net.ipv4.ip_forward=1" | sudo tee /etc/sysctl.d/99-ip-forward.conf
# Writes the setting to a drop-in file so it survives reboots.
# Files in /etc/sysctl.d/ override defaults in /usr/lib/sysctl.d/.
sudo sysctl -p /etc/sysctl.d/99-ip-forward.conf
# Reloads the configuration from the file to verify syntax.
# This confirms the file is readable and the value applies cleanly.

Files in /etc/sysctl.d/ override defaults. Never edit files in /usr/lib/sysctl.d/ as package updates will overwrite them.

Check sysctl net.ipv4.ip_forward after reboot. The value must remain 1.

Configure firewalld zones and masquerading

Fedora uses firewalld to manage the firewall. Zones group interfaces and define trust levels. The external zone is designed for routers. It enables masquerading by default and allows traffic to flow from internal zones to the external zone. The internal zone trusts traffic from the local network. You assign interfaces to zones and enable masquerading to perform NAT.

Some setups require explicit forwarding rules via the direct interface. Direct rules provide packet-filter level control that sits below zone logic. Use direct rules when you need fine-grained control over forwarding chains or when zone defaults do not match your security policy.

Here is how to assign interfaces to zones and enable masquerading with explicit forwarding rules.

sudo firewall-cmd --permanent --zone=external --change-interface=enp1s0
# Assigns the WAN interface to the external zone.
# The external zone enables masquerading by default on Fedora.
sudo firewall-cmd --permanent --zone=internal --change-interface=enp2s0
# Assigns the LAN interface to the internal zone.
# The internal zone trusts traffic from the local network.
sudo firewall-cmd --permanent --zone=external --add-masquerade
# Explicitly enables NAT masquerading for the external zone.
# This rewrites source IPs to the WAN address for outbound traffic.
sudo firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 \
  -i enp2s0 -o enp1s0 -j ACCEPT
# Allows new connections from the LAN interface to the WAN interface.
# Direct rules sit below zone rules and provide packet-filter level control.
sudo firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 \
  -i enp1s0 -o enp2s0 -m state --state RELATED,ESTABLISHED -j ACCEPT
# Allows return traffic for established connections from WAN to LAN.
# This ensures responses to outbound requests are not dropped.
sudo firewall-cmd --reload
# Applies permanent changes to the running firewall.
# Always run this after modifying permanent rules.

Always run firewall-cmd --reload after permanent changes. Runtime and persistent configs diverge instantly if you skip this.

Reload the firewall after every change. Runtime and persistent configs diverge instantly if you skip this.

Provide DHCP to internal clients

Clients on the LAN need an IP address, gateway, and DNS servers. dnsmasq is a lightweight DHCP and DNS server that works well for small networks. It installs quickly and configures via a simple text file. You restrict it to the LAN interface and define the address pool.

Here is how to install and configure dnsmasq for the LAN subnet.

sudo dnf install dnsmasq
# Installs the lightweight DHCP and DNS server.
# dnsmasq is the standard choice for small network DHCP services on Fedora.

Edit the configuration file to define the interface and DHCP options.

interface=enp2s0
# Restricts dnsmasq to listen only on the LAN interface.
dhcp-range=192.168.100.50,192.168.100.200,24h
# Defines the pool of addresses to lease and the lease duration.
dhcp-option=3,192.168.100.1
# Tells clients to use this router as their default gateway.
dhcp-option=6,1.1.1.1,8.8.8.8
# Provides public DNS servers to clients for internet resolution.

Start the service and open the firewall for DHCP traffic.

sudo systemctl enable --now dnsmasq
# Starts the service and ensures it launches on boot.
sudo firewall-cmd --permanent --zone=internal --add-service=dhcp
# Opens UDP port 67 and 68 in the internal zone for DHCP traffic.
sudo firewall-cmd --reload
# Reloads the firewall to apply the new service rule.

Restart dnsmasq after config edits. The service does not reload configuration automatically.

Verify routing

Test connectivity from a client machine on the LAN. Use a public IP address to rule out DNS issues during verification. If ping works but websites fail, the problem is DNS, not routing. If ping fails, check the gateway and firewall.

Here is how to verify connectivity and the routing path from a client.

ping -c 3 1.1.1.1
# Tests basic connectivity to an external IP.
# Use a public IP to rule out DNS issues during verification.
traceroute 1.1.1.1
# Shows the path packets take.
# The first hop must be your router's LAN IP.

Test with a public IP first. DNS failures mask routing problems.

Common pitfalls and error signs

If clients receive an IP address but cannot reach the internet, the gateway is likely misconfigured. Check the client's routing table. The default route must point to the router's LAN IP. If the LAN interface on the router has a gateway set in NetworkManager, the routing table gets confused. Ensure ipv4.gateway "" on the LAN profile.

If dnsmasq fails to start, check the journal for port conflicts. systemd-resolved often listens on port 53 by default. You may need to disable systemd-resolved or configure dnsmasq to use a different port.

journalctl -xeu dnsmasq
# Shows recent logs and explanatory text for the dnsmasq service.
# The x flag adds context. The e flag jumps to the end.
# Look for 'Address already in use' errors.

Run journalctl -xeu dnsmasq before guessing. The log tells you exactly which port is occupied.

If packets drop silently, check SELinux denials. Fedora enforces SELinux by default. If you run custom scripts or non-standard services, SELinux may block network access. Check the setroubleshoot logs for one-line summaries of denials.

journalctl -t setroubleshoot
# Filters journal entries for SELinux denial summaries.
# Read the summary before disabling SELinux.
# Most denials indicate a misconfiguration, not a security flaw.

Read SELinux denials before disabling the policy. Disabling SELinux removes protection without fixing the root cause.

When to use this vs alternatives

Use Fedora as a router when you need a flexible, software-defined gateway that integrates with your existing Linux infrastructure. Use a dedicated appliance like pfSense when you require a hardened, purpose-built firewall with a web GUI and community support for enterprise features. Use a consumer hardware router when you want zero maintenance and plug-and-play setup for a small home network. Stay on Fedora Workstation with a router role if you are comfortable managing services via terminal and want full control over the kernel and packages.

Where to go next