ping fails but dig / nslookup works?

I’ve now run into two scenarios where this happened. The most recent was after I had to kill a vpnc process (used to connect to a cisco VPN).

It looks like this:

[james@workstation ~]$  ping google.com
ping: unknown host google.com

[james@workstation ~]$  dig google.com +short
72.14.204.147
72.14.204.99
72.14.204.103
72.14.204.104

What ended up happening was that the VPN was configured to tunnel all traffic through it, so when it re-wrote the /etc/resolv.conf file, it didn’t append the VPN nameservers to the nameservers provided to us by our DHCP lease, but completely overwrote them. I’m assuming that when you closed the VPN it would replace the resolv.conf file with the one containing the non-VPN nameservers but since I killed it, it was not restored.

Anyway, the fix was easy but finding it out was annoying.

All you have to do is release and renew your DHCP lease.

You could try:

dhclient -r; dhclient

… but I was on an SSH connection and I didn’t quite trust the second command to be run after I lost the connection when the lease was released (this seems like a silly fear but whatever).

Instead I wrote a bash script and put it in a file:

#!/bin/bash
#refreshlease.sh
IFACE="eth0"

dhclient -r ${IFACE}
dhclient ${IFACE}

… and ran that over the SSH connection. The connection seemed to get dropped for a few seconds but then came back up. Checking /etc/resolv.conf showed that my original nameservers were, in fact, back and I was able to resolve DNS queries:

[james@workstation ~]$  ping google.com
PING google.com (64.233.169.105) 56(84) bytes of data.
64 bytes from yo-in-f105.1e100.net (64.233.169.105): icmp_seq=1 ttl=238 time=31.1 ms

Update

Although this worked for me many times, I recently ran into a situation with the same symptoms (ping fails but nslookup worked) but where the /etc/resolv.conf file was fine (it contained nameserver x.x.y.y as it should). The interface was up and correctly assigned an IP address (you can check with ifconfig). In this case, something happened to the machines routing table. You can check the routing table with the route command:

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         DD-WRT          0.0.0.0         UG    0      0        0 eth1

This is what it should look like, but in my case, there was no default route. I needed to add a default route so that any packets that didn’t match other routing rules, would use the default rule. To add a default rule, type

$ route add -net 0.0.0.0 netmask 0.0.0.0 gw X.X.Y.Y

Where X.X.Y.Y is the IP address if your router.

Posted Wednesday, January 20th, 2010 under linux, networking, shell scripting.

Leave a Reply