Troubleshoot Default Routes in Linux

Traffic to the internet leaves through one default gateway — but the routing table can list the wrong via address, two competing default lines, or no default at all. Symptoms range from network is unreachable on every remote IP to packets exiting the slow lab NIC while the uplink sits idle.

The steps below read the installed default, ask the kernel which route it would pick, use metrics to explain multiple gateways, fix bad entries, and persist the correct profile with NetworkManager.

Check the current default route

The default route is the catch-all for destinations that do not match a more specific prefix. List only those lines:

ip -4 route show default

On the lab host the uplink NIC owns the internet path:

default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 116

Read the fields together:

• via 10.0.2.2 — next-hop gateway router
• dev enp0s3 — outbound interface
• proto dhcp — NetworkManager or DHCP installed this route
• metric 116 — preference when more than one default exists

No output means off-subnet traffic has no path until you add a default — see network is unreachable when ping to remote IPs fails with that message.

List the full IPv4 table when you need connected subnets beside the default:

ip -4 route

default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 116
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 116
192.168.56.0/24 dev enp0s8 proto kernel scope link src 192.168.56.116 metric 117

The 192.168.56.0/24 line is a direct link route — LAN peers use enp0s8 without touching the default gateway.

Check which route Linux actually selects

The routing table can list several defaults; ip route get shows the one the kernel chooses for a specific destination:

ip route get 8.8.8.8

8.8.8.8 via 10.0.2.2 dev enp0s3 src 10.0.2.15 uid 0
    cache

via and dev here are authoritative — this is the path ping, curl, and ssh use for that address. Compare against a peer on the local subnet:

ip route get 192.168.56.220

192.168.56.220 dev enp0s8 src 192.168.56.116 uid 0
    cache

No via line means the kernel uses the connected route on enp0s8, not the default gateway. When ip route get prints RTNETLINK answers: Network is unreachable, there is no matching route — add or fix the default before you chase DNS or firewalls.

Understand route metrics

Metric is a cost or preference value on a route. For two equally specific routes — including two default lines — the kernel prefers the lower metric.

The lab uplink uses metric 116 and the LAN interface link route uses 117. DHCP and NetworkManager often assign close metrics per interface; manual routes need an explicit metric when you add them.

Add a second default on the lab NIC with a high metric so it does not steal traffic:

sudo ip route add default via 192.168.56.99 dev enp0s8 metric 200

List both defaults:

ip -4 route show default

default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 116
default via 192.168.56.99 dev enp0s8 metric 200

Ask the kernel which path it still picks for the internet:

ip route get 8.8.8.8

8.8.8.8 via 10.0.2.2 dev enp0s3 src 10.0.2.15 uid 0
    cache

Metric 116 beats 200, so traffic stays on enp0s3. Remove the lab default before you continue:

sudo ip route del default via 192.168.56.99 dev enp0s8 metric 200

When the wrong default has the lower metric, ip route get follows it — covered in the next section.

Fix an incorrect default route

A default pointing at a dead gateway or the wrong interface sends every off-subnet packet into a black hole. On the lab host I added a bogus default with metric 50 — lower than the real uplink — to reproduce that mistake:

sudo ip route add default via 192.168.56.99 dev enp0s8 metric 50

Confirm the kernel switched paths:

ip route get 8.8.8.8

8.8.8.8 via 192.168.56.99 dev enp0s8 src 192.168.56.116 uid 0
    cache

Remote traffic now leaves enp0s8 toward a gateway that does not exist on the LAN. Delete the bad entry with the same via, dev, and metric you used when adding it:

sudo ip route del default via 192.168.56.99 dev enp0s8 metric 50

If the table had no correct default left, add the known-good gateway on the uplink:

sudo ip route replace default via 10.0.2.2 dev enp0s3

ip route replace adds or updates the route in one step. Re-check selection:

ip route get 8.8.8.8

8.8.8.8 via 10.0.2.2 dev enp0s3 src 10.0.2.15 uid 0
    cache

Manual ip route changes last until reboot or until NetworkManager reapplies the profile — use them to prove the gateway, then persist through nmcli below.

Troubleshoot multiple default routes

Servers with two NICs, laptops on Wi-Fi and Ethernet, or VPN clients often accumulate more than one default via line. List them all:

ip -4 route show default

Two lines are not automatically wrong — compare metrics and ip route get for the destinations you care about. The broken pattern is a low-metric default on a LAN-only interface.

Check what NetworkManager learned on each device:

nmcli dev show enp0s3 | grep IP4.GATEWAY

IP4.GATEWAY:                            10.0.2.2

On a secondary NIC that should never carry internet traffic:

nmcli dev show enp0s8 | grep IP4.GATEWAY

IP4.GATEWAY:                            --

-- on enp0s8 is expected for an isolated lab segment — the uplink profile should own the only default. If DHCP on a secondary NIC installs an unwanted default, block it on that connection profile:

sudo nmcli connection modify enp0s8 ipv4.never-default yes

Reactivate so the setting applies:

sudo nmcli connection up enp0s8

ipv4.never-default yes stops NetworkManager from installing a default route from that profile while leaving LAN addresses intact. Remove stray manual defaults with ip route del and verify with ip route get before you close the change ticket.

Make the route persistent

ip route add and ip route del are lost on reboot unless something in your network stack reinstalls them. On NetworkManager-managed hosts, the connection profile owns the gateway.

Inspect the uplink profile:

nmcli connection show enp0s3 | grep -E 'ipv4\.(method|gateway|route-metric)'

ipv4.method:                            auto
ipv4.gateway:                           --
ipv4.route-metric:                      -1

ipv4.gateway shows -- because DHCP supplies the gateway at runtime — the live value still appears in ip route show default and nmcli dev show. For a static uplink, set address and gateway on the profile:

sudo nmcli connection modify enp0s3 ipv4.method manual ipv4.addresses '10.0.2.15/24' ipv4.gateway '10.0.2.2' ipv4.dns '8.8.8.8'

Apply the profile:

sudo nmcli connection up enp0s3

The gateway must sit on a subnet connected to enp0s3 — a via address outside the interface prefix leaves you with the same unreachable errors as a wrong manual route.

Prefer the lab NIC for outbound traffic only when you intend it — lower the metric on that profile, not the uplink:

sudo nmcli connection modify enp0s3 ipv4.route-metric 100

On Debian and Ubuntu with Netplan, put gateway4 or routes: [{ to: default, via: … }] in the correct YAML file and apply with netplan apply. After edits on Ubuntu desktops, see refresh network on Ubuntu.

Verify route selection

After every change, confirm the kernel still picks the gateway you expect — do not rely on the routing table alone when multiple defaults exist.

ip -4 route show default

default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 116

Ask the kernel which path it would use for an off-subnet address:

ip route get 8.8.8.8

8.8.8.8 via 10.0.2.2 dev enp0s3 src 10.0.2.15 uid 0
    cache

Matching via and dev on both commands means off-subnet traffic uses the uplink. Test a LAN peer to confirm local traffic does not hairpin through the default:

ip route get 192.168.56.220

192.168.56.220 dev enp0s8 src 192.168.56.116 uid 0
    cache

ping or curl to a remote IP can still fail when ICMP is filtered upstream even though routing is correct — pair route checks with test port connectivity on the TCP port your application uses. If the gateway is right but transfers are slow, continue with Linux slow network troubleshooting.

Troubleshooting

References

• ip-route(8) — Linux manual page
• NetworkManager nm-settings-nmcli(5)
• Red Hat — Configuring IP networking

Summary

Linux default route problems start with ip -4 route show default — the via, dev, and metric fields tell you what is installed. ip route get DESTINATION is the decisive check because it shows which default the kernel actually selects, which matters the moment you have more than one default via line.

Metrics break ties: lower wins among routes of the same specificity. A secondary NIC with a better metric steals internet traffic even when the uplink looks fine in nmcli. Delete bad entries with ip route del, restore with ip route replace, and block unwanted DHCP defaults using ipv4.never-default on secondary NetworkManager profiles.

Persistence belongs in the connection profile — ipv4.gateway and ipv4.method for static uplinks, DHCP on the interface that should own the default, or Netplan on Ubuntu. Verify with matching output from ip route show default and ip route get for both a remote IP and a LAN peer. When the default is missing entirely, work through network is unreachable; when the gateway answers but transfers stall, check destination host unreachable and link-level guides next.