Missing Default Route After Network Change
Embed This Widget
Add the script tag and a data attribute to embed this widget.
Embed via iframe for maximum compatibility.
<iframe src="https://ipfyi.com/iframe/entity//" width="420" height="400" frameborder="0" style="border:0;border-radius:10px;max-width:100%" loading="lazy"></iframe>
Paste this URL in WordPress, Medium, or any oEmbed-compatible platform.
https://ipfyi.com/entity//
Add a dynamic SVG badge to your README or docs.
[](https://ipfyi.com/entity//)
Use the native HTML custom element.
A server or device loses internet connectivity after a network configuration change because the default route (0.0.0.0/0) is missing from the routing table. Without a default route, the kernel does not know where to send packets destined for addresses outside directly connected subnets, causing all outbound connections to fail while local network communication continues to work normally.
Symptoms
- ⚠ Server can reach other devices on the local LAN but cannot connect to the internet
- ⚠ DNS resolution fails because the DNS server (e.g., 8.8.8.8) is outside the local subnet
- ⚠ `ip route show` on Linux or `route print` on Windows shows no 0.0.0.0/0 entry
- ⚠ ping to the local gateway (e.g., 192.168.1.1) succeeds but ping to 8.8.8.8 fails
- ⚠ Problem appeared immediately after editing network configuration files or running a script
- ⚠ Rebooting the server does not restore connectivity — the misconfiguration persists
Possible Root Causes
- • Network configuration file edited manually and the `gateway` or `gateway4` directive was accidentally deleted or misspelled
- • DHCP client service stopped or lease expired and was not renewed, removing the dynamically-assigned default route
- • Interface was brought down and up with `ifdown`/`ifup` or `ip link set down/up` without the routing configuration script running
- • Cloud instance metadata service unreachable during boot, preventing the DHCP lease and default route from being assigned
- • Static route configuration script failed silently after a package upgrade or OS update changed the network stack
Diagnosis Steps
Step 1: Confirm the Default Route is Missing
# Linux
ip route show
# A healthy output includes a line like:
# default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.100 metric 100
# If the default line is absent, you have no default route.
# macOS
netstat -rn | grep default
# Should show: default 192.168.1.1 UGScg en0
# Windows
route print | findstr "0.0.0.0"
# Should show: 0.0.0.0 0.0.0.0 192.168.1.1 ...
Step 2: Verify Local Gateway is Reachable
# Find the gateway from the local interface
ip route show | grep "link src"
# Or read the subnet: ip addr show eth0
# Ping the gateway
ping -c4 192.168.1.1
# If the gateway is also unreachable, the problem is at Layer 2 (cable, switch, VLAN)
Step 3: Check DHCP Client Status
# If the interface uses DHCP, confirm the client is running and received a lease
systemctl status dhclient
# or for systemd-networkd:
networkctl status eth0
# Renew the DHCP lease
sudo dhclient -r eth0 # release
sudo dhclient eth0 # renew
# Verify the route was added after renewal:
ip route show | grep default
Step 4: Examine Network Configuration Files
# For static configuration, check the file that was edited:
# Debian/Ubuntu (interfaces):
cat /etc/network/interfaces | grep gateway
# Ubuntu Netplan:
cat /etc/netplan/*.yaml | grep gateway4
# RHEL/CentOS (nmcli):
nmcli connection show eth0 | grep IP4.GATEWAY
# or
cat /etc/sysconfig/network-scripts/ifcfg-eth0 | grep GATEWAY
Step 5: Test with a Temporary Manual Route
# Add a temporary default route to verify this is the issue
sudo ip route add default via 192.168.1.1 dev eth0
# Test connectivity
ping -c4 8.8.8.8
curl -I https://example.com
# If it works, the issue was the missing route — now make it permanent
Solution
Fix: Add the Default Route Immediately
# Linux — temporary fix (lost on reboot)
sudo ip route add default via 192.168.1.1 dev eth0
# Verify
ip route show | grep default
ping -c4 8.8.8.8
Fix: Make it Permanent — Debian/Ubuntu (interfaces)
# /etc/network/interfaces
sudo nano /etc/network/interfaces
# Ensure the following stanza is present:
# iface eth0 inet static
# address 192.168.1.100
# netmask 255.255.255.0
# gateway 192.168.1.1
sudo systemctl restart networking
Fix: Make it Permanent — Ubuntu Netplan
# /etc/netplan/01-netcfg.yaml
network:
version: 2
ethernets:
eth0:
addresses:
- 192.168.1.100/24
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses: [8.8.8.8, 1.1.1.1]
sudo netplan apply
ip route show | grep default
Fix: Make it Permanent — RHEL/CentOS (nmcli)
sudo nmcli connection modify eth0 ipv4.gateway 192.168.1.1
sudo nmcli connection up eth0
Fix: Re-enable DHCP
# If DHCP should be used:
# Debian/Ubuntu
sudo dhclient eth0
# RHEL/CentOS
sudo nmcli connection modify eth0 ipv4.method auto
sudo nmcli connection up eth0
Prevention
- Use configuration management (Ansible, Chef, Puppet) to manage network files — human-edited files are error-prone
- Validate network configuration with
netplan generate(Ubuntu) ornmcli connection verifybefore applying - Test connectivity immediately after any network change:
ping 8.8.8.8andcurl -I https://example.com - For cloud instances, enable instance monitoring that alerts on loss of outbound internet connectivity within 60 seconds
- Keep a console or out-of-band access path (BMC, cloud serial console) available so misconfigured network changes can be reversed without needing the broken network connection
Related Protocols
Related Terms
More in VPN & Routing
Asymmetric Routing with Stateful Firewall Dropping Packets
Advanced
DNS Leaking Outside VPN Tunnel
Beginner
IPsec Phase Negotiation Failure (IKEv1/IKEv2)
Advanced
OSPF Adjacency Not Forming Between Neighbors
Advanced
Routing Loop Causing TTL Exceeded Errors
Intermediate
Split-Tunnel VPN Routing Misconfiguration
Intermediate