"I can ping the gateway" is not "I have internet"

A short one, prompted by a rabbit hole I cheerfully fell down so you don't have to.

I was trying to get a server online through a wired segment. The gateway answered ping instantly — sub-millisecond, rock solid — so I happily built routing on top of it, added a default route, fiddled with NAT, and spent a good while wondering why nothing could actually reach the outside world. Traceroute made it for exactly one hop (the gateway) and then * * * forever.

The penny dropped eventually, and it's embarrassing: that segment had no path to the internet at all. The gateway was alive on the LAN but had no working uplink — and my own laptop's internet, the whole time, was coming over wifi, not the wired NIC I was so busy debugging. I'd been routing through a door that opened onto a wall, and "the gateway pings" had lulled me into assuming there was a building on the other side.

The lesson, and the test

Pinging your next hop proves layer-2/3 reachability to that device. It proves nothing about whether that device can route you to the internet. They're completely separate facts, and conflating them will waste your afternoon.

So test the thing you actually care about — reachability to the outside, over TCP and DNS, not ICMP to the gateway:

# does a real host answer over TCP 443?
curl -sS -m8 -o /dev/null -w "%{http_code}\n" https://github.com
# does DNS resolve to the outside?
getent hosts github.com
# unsure if a captive portal is faking it? a 204 endpoint won't be faked by a portal
curl -sS -m8 -o /dev/null -w "%{http_code}\n" http://connectivitycheck.gstatic.com/generate_204   # want 204

If those work, you have internet. If they don't, it doesn't matter how beautifully your gateway pings. (And ICMP to 1.1.1.1 is a poor proxy too — plenty of networks firewall outbound ping while passing TCP and DNS perfectly well, so a failed ping 1.1.1.1 can also lie to you, in the other direction.)

Verify the upstream, not the next hop. Ta ta for now.