4

While trying to ping www.google.com I was getting the error:

;; connection timed out; no servers could be reached

I was neither able to run sudo apt-get update and nor able to access any webpages. So I edited my /etc/resolv.conf file to contain OpenDNS servers so it looked something like this:

~$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# OpenDNS IPv4 nameservers
nameserver 208.67.222.222
nameserver 208.67.220.220

However, I am still getting the same error:

~$ host -v www.google.com Trying "www.google.com" ;; connection timed out; no servers could be reached

I tried it with dig as well, and the results are:

:~$ dig @8.8.8.8 www.google.com

; <<>> DiG 9.9.5-3ubuntu0.4-Ubuntu <<>> @8.8.8.8 www.google.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached

Could anyone please help me resolve the problem? I am running Ubuntu 14.04 on VirtualBox.

EDIT:

ifconfig's output:

eth0      Link encap:Ethernet  HWaddr 08:00:27:6a:81:38  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe6a:8138/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8368 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5197 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:7814822 (7.8 MB)  TX bytes:467136 (467.1 KB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:409 errors:0 dropped:0 overruns:0 frame:0
          TX packets:409 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:42236 (42.2 KB)  TX bytes:42236 (42.2 KB)

ip route's output:

~$ ip route default via 10.0.2.2 dev eth0  proto static 
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15  metric 1
  • Show output of ifconfig and ip route. Virtualbox network is set to NAT or BRIDGED or something else ? – EdiD Mar 9 '16 at 11:41
  • @EdiD just did above in the original post. – QPTR Mar 9 '16 at 12:01
  • What about host system? firewall status/config on host and guest – EdiD Mar 9 '16 at 12:08
  • So, I just restarted my Ubuntu and its working now. As in the resolution is happening fine. I am still getting an error on trying to run tor though: Can't complete SOCKS5 connection to 0.0.0.0:0 but that may be unconnected? Anyway, for general resolution its working. What does the firewall status/config indicate? – QPTR Mar 9 '16 at 12:12
  • 1
    I was just wondering maybe firewall is blocking your outgoing traffic – EdiD Mar 9 '16 at 12:14
8

As soon as I had the same situation and reboot did not solve the problem here is my simple steps which could help to find the problem:

  1. check internet connection

    ping 8.8.8.8

If destination is unreachable check if your gateway 10.0.2.2 is reachable. And fix the problem.

if connection is fine you would see something like :

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=46 time=4.13 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=4.13 ms
  1. Check if host/dig send packets properly:

    sudo tcpdump -n -i eth0 |grep 8.8.8.8.53

At the same time from another console in the same machine

dig @8.8.8.8 www.google.com

You will get response similar to:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:34:00.980550 IP 10.0.2.15.56570 > 8.8.8.8.53: 47059+ A? google.com. (27)
13:34:05.980541 IP 10.0.2.15.56570 > 8.8.8.8.53: 47059+ A? google.com. (27)

This means that the request had pass to the external network but did not come back...

You can check what your firewall doing by analysing output of your firewall rules:

iptables -n -L

The problem might be from any firewall between you and 208.67.222.222 or 208.67.220.220 or 8.8.8.8

in my case provider's firewall coincidently block incoming UDP packets from 53 port.

and thus correction of providers firewall rules fix the problem.

Hope this analysis would be helpful to someone.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.