Loading...

VONDS ©

Lab 130: Networking Fundamentals — Restore Connectivity

Back to Lab Index

Restore outbound connectivity and name resolution when the host can reach the gateway but cannot reach public IPs and DNS names fail. Confirm interface state, restore a missing default route, then correct DNS via NetworkManager and verify HTTP access.

networking routing dns troubleshooting core

Scenario

A VM on a training network reports: “I can ping the gateway, but the internet is down and DNS names fail.” You have console access and must confirm IP configuration, confirm routing, confirm DNS, fix the issue, and verify access to http://example.com.

Network facts

Interface: eth0. Expected gateway: 10.0.2.2. Expected DNS server: 10.0.2.3. Test site: http://example.com.

Objective

  • Confirm eth0 is up and has an IPv4 address.
  • Prove reachability to the gateway 10.0.2.2.
  • Inspect the routing table and detect a missing default route.
  • Restore the default route and verify internet reachability by IP.
  • Inspect resolver configuration and detect an incorrect DNS server.
  • Set DNS to 10.0.2.3 via NetworkManager and verify name resolution and HTTP access.

Concepts

“Internet is down” is not a single failure. You isolate it in layers:

  • Interface and IP: the NIC is up and has a correct address/prefix.
  • Local path: you can reach the gateway (same subnet).
  • Routing: you can reach the gateway but cannot reach public IPs because there is no default route.
  • DNS: you can reach public IPs but hostnames fail because the resolver is wrong.
Order matters

Always prove public IP connectivity before you chase DNS. If ping 1.1.1.1 fails, DNS is not the root cause yet.

Walkthrough

Step 1: Confirm eth0 has an IPv4 address.
Command 
ip -4 addr show eth0

If the interface has no IPv4 address, do not troubleshoot DNS yet. You need working addressing first.

Step 2: Prove the gateway is reachable.
Command 
ping -c 2 10.0.2.2

This confirms local L2/L3 connectivity. If this fails, fix the local network before anything else.

Step 3: Test public IP reachability (bypass DNS).
Command 
ping -c 2 1.1.1.1

If the gateway ping works but this fails, routing is usually broken (often a missing default route).

Step 4: Inspect the routing table.
Command 
ip route

You should see a line starting with default via .... If it is missing, the host has no path to networks outside its subnet.

Step 5: Add the missing default route.
Command 
sudo ip route add default via 10.0.2.2 dev eth0
Note

This restores routing immediately but may not persist across reboot depending on how networking is managed. The lab focuses on incident-style restore first.

Step 6: Re-test public IP reachability.
Command 
ping -c 2 1.1.1.1

If this now works, routing is fixed. Move on to DNS.

Step 7: Inspect DNS configuration (systemd-resolved stack).
Command 
resolvectl status

Check which DNS servers are assigned to eth0. In this lab, the DNS server is incorrect and must be set to 10.0.2.3.

Step 8: Find the active NetworkManager connection name for eth0.
Command 
nmcli -t -f DEVICE,NAME con show --active | grep '^eth0:'

You will use the connection name from this output in the next steps.

Step 9: Set IPv4 DNS to 10.0.2.3 on the active connection.
Command 
sudo nmcli con mod "<CONNECTION_NAME>" ipv4.dns "10.0.2.3"

This updates the NetworkManager profile instead of editing /etc/resolv.conf by hand.

Step 10: Apply the change (without reboot).
Command 
sudo nmcli con up "<CONNECTION_NAME>"

Bringing the connection up re-applies the profile and pushes the DNS change into the resolver stack.

Step 11: Verify name resolution and HTTP access.
Command 
getent hosts example.com
curl -I http://example.com

First prove DNS resolves the name, then prove end-to-end application connectivity with an HTTP request.

Breakpoints

Gateway ping works, but 1.1.1.1 still fails after adding default route

The upstream device may block egress ICMP, NAT may be broken, or the VM network may be isolated. In real systems, follow up with traceroute or tracepath and firewall/policy checks.

DNS still fails after nmcli change

Confirm the change landed with resolvectl status, verify you modified the correct active connection, and re-check whether the environment expects additional DNS servers or search domains.

Route change disappears later

ip route add is runtime state. Persist it in the network manager used by the system so it survives reboot.

Name resolution works, but HTTP fails

Pivot away from DNS. Check proxies, firewall egress rules, and whether HTTP is blocked while ICMP is allowed.

Cleanup checklist

If you need to revert changes after the lab, remove the runtime default route you added and clear the connection DNS override.

Commands 
sudo ip route del default via 10.0.2.2 dev eth0

sudo nmcli con mod "<CONNECTION_NAME>" ipv4.dns ""
sudo nmcli con up "<CONNECTION_NAME>"

ip route
resolvectl status
Success signal

The default route matches the intended state for your environment, and DNS servers shown under Link (eth0) reflect the active NetworkManager profile.

Reference

  • ip -4 addr show <iface>: show IPv4 addressing and interface state.
  • ip route: inspect the routing table and default route.
  • ip route add default via <gw> dev <if>: add a runtime default route.
  • ip route del default via <gw> dev <if>: remove a runtime default route.
  • ping -c N <ip>: test reachability (use an IP to bypass DNS).
  • resolvectl status: inspect resolver state and per-link DNS servers.
  • nmcli con show --active: list active NetworkManager connections.
  • nmcli con mod "<con>" ipv4.dns "<server>": set DNS for a connection profile.
  • nmcli con up "<con>": re-apply a NetworkManager profile.
  • getent hosts <name>: validate NSS name resolution.
  • curl -I <url>: confirm HTTP connectivity by checking response headers.
  • tracepath <host>: inspect path behavior and discover MTU/routing issues.