Fix Network Is Unreachable on Linux

ping 8.8.8.8 answers with connect: Network is unreachable while ping 192.168.56.220 on the same LAN still works. That pattern means the host has link connectivity locally but the kernel cannot pick a path to addresses outside your connected subnets — usually a missing or wrong default route.

Work through interface state, then ip route get, then the gateway and NetworkManager profile that should install it.

What network is unreachable means

Linux returns ENETUNREACH when the routing table has no entry for the destination and no default route covers it. Tools phrase it differently:

This is not a DNS failure — use an IP address in your first test so name lookup stays out of the path. If only hostnames fail while IPs work, see temporary failure in name resolution instead.

Check interface state and IP address

A route cannot work if the outbound interface is down or has no IPv4 address. List link state first:

ip -br link

Sample output:

lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp0s3           UP             08:00:27:2d:cd:83 <BROADCAST,MULTICAST,UP,LOWER_UP>
enp0s8           UP             08:00:27:c4:4f:20 <BROADCAST,MULTICAST,UP,LOWER_UP>

UP in the state column and LOWER_UP in the flags mean the NIC is administratively up and sees carrier. DOWN or missing LOWER_UP on the interface you expect to use needs a link fix before you chase gateways.

Confirm the interface that should reach the internet has an address:

ip -4 addr show enp0s3

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute enp0s3
       valid_lft 86395sec preferred_lft 86395sec

An inet line with a mask shows the host is addressed on that subnet. No inet line means DHCP may have failed or the profile is static without an address — reconnect or fix the NetworkManager profile before adding routes.

Check route selection with ip route get

ip route get shows which interface and source IP the kernel would use for a destination. Run it against a remote IP you cannot reach:

ip route get 8.8.8.8

When routing works, you get a via gateway and dev interface:

8.8.8.8 via 10.0.2.2 dev enp0s3 src 10.0.2.15 uid 0
    cache

When no route matches, the kernel answers immediately:

ip route get 8.8.8.8

RTNETLINK answers: Network is unreachable

That response is the same condition ping reports — there is no path in the table for that destination.

List the full IPv4 table for context:

ip -4 route

Sample output on a host missing the default route:

10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 112
192.168.56.0/24 dev enp0s8 proto kernel scope link src 192.168.56.116 metric 113

Only scope link entries for directly connected subnets and no default via … line explains why off-subnet addresses are unreachable. For flag and metric detail, see ip route command.

Check the default gateway

The default route sends traffic to destinations outside your local subnets. Look for it explicitly:

ip -4 route show default

Working output:

default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 112

No output means every off-subnet destination will hit network is unreachable until you add a default route.

NetworkManager stores the gateway it learned from DHCP on the device view — replace enp0s3 with your uplink interface:

nmcli dev show enp0s3 | grep IP4.GATEWAY

IP4.GATEWAY:                            10.0.2.2

A lab-only NIC often has no gateway by design:

nmcli dev show enp0s8 | grep IP4.GATEWAY

IP4.GATEWAY:                            --

Traffic to the internet must leave through the profile that has a gateway, not the isolated lab interface.

Fix a missing or incorrect route

Pick a fix that matches how the host is managed. These examples use gateway 10.0.2.2 on enp0s3 — substitute your gateway IP and interface from ip route show default or nmcli dev show.

Temporary default route with ip route

For a quick test or rescue session, add a default route manually:

sudo ip route add default via 10.0.2.2 dev enp0s3

Confirm the kernel now selects a path:

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

ip route add lasts until reboot or until NetworkManager reapplies the profile. Use it to prove the gateway is correct, then make the change persistent through NetworkManager or your netplan config.

Static default on a single subnet

If the host should reach only one remote network, not the whole internet, add a narrower route instead of a default:

sudo ip route add 203.0.113.0/24 via 10.0.2.2 dev enp0s3

Verify with ip route get against an address inside that prefix. Default routes are still the common fix for general internet access.

Check NetworkManager configuration

On NetworkManager-managed systems, the connection profile owns addresses, gateway, and DNS. See which profile is active:

nmcli device status

DEVICE  TYPE      STATE                   CONNECTION
enp0s3  ethernet  connected               enp0s3
enp0s8  ethernet  connected               enp0s8
lo      loopback  connected (externally)  lo

If the default route disappeared after a manual ip route del, reactivating the uplink profile often restores DHCP routes:

sudo nmcli connection up enp0s3

Check the routing table again:

ip -4 route show default

default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 114

For a static uplink, set the gateway on the profile so it survives reboot — adjust addresses to match your network:

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

ipv4.gateway must point at a router on a connected subnet. A gateway outside the interface subnet leaves you with the same unreachable errors.

On Debian and Ubuntu with Netplan or systemd-networkd, the same logic applies — gateway belongs in the LAN profile. After edits, use refresh network on Ubuntu steps to apply without a full reboot.

Verify connectivity

Re-run the same checks that failed before.

Routing decision:

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

ICMP to a public resolver:

ping -c2 -W3 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=19.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=18.7 ms

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Some networks block ICMP. If ip route get looks correct but ping shows loss, test TCP with test port connectivity or curl -sI --max-time 5 https://1.1.1.1.

Confirm local LAN traffic still works on interfaces without a default route:

ping -c1 -W2 192.168.56.220

PING 192.168.56.220 (192.168.56.220) 56(84) bytes of data.
64 bytes from 192.168.56.220: icmp_seq=1 ttl=64 time=1.21 ms

Replies here with a restored default route confirm both the lab path and the internet path.

Network is unreachable vs no route to host

Both errors sound like routing problems but point at different layers:

ping to an unused address on the same subnet often ends in 100% packet loss after ARP times out — not the same as network is unreachable, which appears before any packet leaves for off-subnet destinations.

SSH and other TCP clients can print no route to host when a firewall REJECTs the connection even though ip route get looks healthy. Walk through Fix SSH no route to host when routing checks pass but one service still fails.

Troubleshooting

References

• ip-route(8) — routing table management
• ip(8) — link and address inspection
• NetworkManager ip4 settings — gateway, method, and route properties
• RFC 1122 — Requirements for Internet Hosts — host routing behavior

Summary

Network is unreachable means the kernel routing table has no usable path to the destination. The quickest signal is ip route get on a remote IP — when it answers RTNETLINK answers: Network is unreachable, you are looking at a missing default route or a missing static route, not DNS or a down web server.

Start with interface state and addresses, read ip -4 route for a default via line, and confirm the gateway lives on the uplink profile that actually reaches your router. A manual ip route add default proves the gateway; nmcli connection modify with ipv4.gateway keeps it across reboots on NetworkManager hosts.

Local subnet pings can still succeed while every internet IP fails — that split is normal when only the default route is wrong. If routing checks pass but SSH prints no route to host instead, shift to firewall and neighbor troubleshooting rather than adding more routes.

For day-to-day route inspection and persistent static routes, keep ip route command and nmcli command examples nearby.