Menu
Host-only networking allows your guest to access your host and your guest to access other guests. However, it does not allow network traffic to pass between the guest to the real physical network beyond the host, including the internet. You are unable to ping 8.8.8.8 because that machine is neither your host nor one of your virtual machines.
I can not open a specific website. This is a website hosted by our company, and I know it is up. However, these are my symptoms:
- If I go to the browser and open
http://host.com
, then it gives me an error (Unable to Connect in Firefox; Page not Available in Chrome) - If I run
ping host.com
, it returns:
Please note that
192.168.0.121
is the IP of my own machine. - A traceroute will also fail miserably:
And I have already checked the following:
- The website is available just fine from any other computer in our network
- If I try to ping or traceroute the IP directly, the results are the same
- This IP or website is not listed in my
/etc/hosts
- There is no firewall rule interfering. I even flushed all rules and tried again; same results.
What can it be?
EDIT:
Connectivity to this particular IP just came back. I can now connect to this website again. But this has happened before: I can connect, and then I cannot connect. It comes and goes, whereas for other computers in the network and for all other people in the public, this site is online all the time.
EDIT 2:
The problem is back. We just had an internet failure and have reset the router, and on all computers internet works just fine. On my computer, internet itself is also fine. It's just this particular domain name. I expect this to mysteriously work again in half an hour or so, but in the meantime I try to debug this issue. Here come some data as requested:
user
useruser
5 Answers
Is there a chance that your IP is duplicated on the network?
Given that you have done all of this testing the next step would be to use an intermediate hop in between and go to the website from your computer.
Use a free
proxy
online. There are several available. I have seen this issue before and it turned out that the IP was being blacklisted
blackholed
by the destination system for a period of time. Fail2ban
has the ability to block an IP for a specified amount of time.If you can get there from an internet proxy then use a hop closer. Set a forward on another system inside your network, or SSH to another system and try to hit the site. If you still cannot, then the only variable left is the destination machine or the router in between.
Note: I am not a networking guy. But, possibly a cached arp listing with your IP and a different mac, something else on the router that has your IP is blocking it for some reason?
Edit:
Things to try:
- Internet Proxy
- Intermediate hop
- Check / Clear your
arp
cache - Boot from a Live CD and try the site
- ----this will take your OS out of the equation
- ----if the Live CD works - set your IP to be the same as normal
- Change your MAC address
- Setup a virtual interface eth0:1
Changing your MAC:
ifconfig -a | grep -i hwaddr
ifconfig eth0 down
ifconfig eth0 hw ether 00:00:00:00:00:00
(replace with a different MAC)ifconfig eth0 up
2bc2bc
If you did not change anything it must be something outside your control - my guess that this a router interfering or changing routes on the way to your target.
ip route get 192.168.1.121
would be interesting, too. Your error-messages seem to indicate a local routing problem.Update: This looks quite 'normal' on your computer.
I just had the same idea as 'LinuxlyChallenged': Duplicate IP or duplicate MAC.
To check for a duplicate IP:
If this does not return 'Bad luck...' - i.e. no one else answers your RARP, reconfigure your IP to eth0 and go ahead with changing your MAC (see answer from LinuxlyChallenged - section 'Changing your MAC'.
NilsNils
I meet similarity problem, I ping github.com(192.30.253.112) fail.
I found the key problem after I haven seen your comments
note that the third route means when I visit
192.xxx.xxx.xxx
, It will be some error.so remote this route, then I ping github.com
successful.chenghao dengchenghao deng
I had the same issue, in my case, it was docker installed, which has a network called docker0 with ip 172.17.0.1.
In my case I shut down the interface docker0 with the command
sudo ifconfig docker0
down and every thing went well.AlejoTamayoAlejoTamayo
In my case the machine was a virtual machine in a proxmox hypervisor and the network card had a virtual lan (vlan) configuration set to tag 30. After removing this (no tag), I could ping the other machine successfully.
janjan
Not the answer you're looking for? Browse other questions tagged networkinginternetping or ask your own question.
I've got two computers in a LAN behind a wireless router.
One has XP with ip 192.168.1.2
This one has W7 with ip 192.168.1.7
If I try to ping the other one from this computer, I get this:
Tracert gives the same result:
Although I can ping and tracert the router without any problems. I have disabled the firewalls on both computers. The router is set to use DHCP (if that matters).
Here is the output from 'route'.
I've set up and debugged a few networks in my life but I'm not really an advanced network user, so I'm not sure what might be wrong. Any ideas? Oh, and pinging this computer from the other computer doesn't work either.
EDIT: Adding arp output:
Adding ipconfig...
Srekel
SrekelSrekel
5 Answers
There are plenty of cheap 802.11 APs and client cards out there with broken multicast* support, especially when encryption is enabled, and especially especially when WPA2 Mixed Mode (AES-CCMP simultaneously with TKIP) or 802.11i TSN (AES-CCMP and/or TKIP simultaneously with WEP) is enabled.
*Note: In 802.11, broadcast is a subset of multicast: it's a multicast that goes to everyone. So when I say 'multicast', think 'multicast/broadcast'.
On 802.11, multicast is trickier in the AP -> client direction, because it has to be sent at a lowest-common-denominator multicast rate, it isn't ACKed or resent at the 802.11 layer, and if you have WPA or WPA2 encryption on, it has to be sent encrypted with a different key (the group key), and if you have WPA2 Mixed Mode or 802.11i TSN on, it has to be sent not only with a different key, but with a different cipher (a lowest-common-denominator cipher; TKIP in the case of WPA2 Mixed Mode, and WEP in the case of TSN).
One quick way to see if it's just multicast problem is to manually add static ARP entries on each machine, so they know the 'IP address -> wireless MAC address' mappings of each other, and then see if you can ping. ARP uses broadcasts, so broken multicasts on an 802.11 network breaks the ability of a wireless client to receive ARP broadcasts when other clients are trying to look up the wireless client's MAC address. Without the ARP mapping, the ping frame can't be addressed at the 802.11 layer, so it can't be transmitted.
If static ARP mappings fixes it, try temporarily turning off all wireless encryption, then delete your static ARP mappings and try your test again. If ARP works this time, it's a sign that multicast is not completely broken on your 802.11 equipment, it's just broken when encryption is on.
About now, some might be asking, 'But if broadcasts are broken, why did DHCP work? DHCP uses broadcasts!', and you're right that DHCP uses broadcasts, but in DHCP only the messages from the client to the server are broadcast. In the other direction, they're usually unicast. And it's only in the to the client direction that multicasts are tricky in 802.11.
Check with your AP and client card vendor for firmware and driver updates. Always buy Wi-Fi certified 802.11 gear, because the Wi-Fi certification testing specifically tests to ensure multicast works even when crypto is on. Please also 'name and shame' the vendors of the AP and client card(s) in question.
When multicast is broken between an AP and a client, I can't think of an easy way to tell if the fault is with the AP or the client, other than process-of-elimination, by seeing if other brands of wireless clients have the same problem on that AP, and seeing if that wireless client has the same problem on other brands of APs.
The more advanced way to pin the blame on one end or the other is to use another machine that's not part of the test, but has an 802.11 card, to do an 802.11 monitor mode packet trace, starting from before the wireless client associates. Someone well-versed in 802.11 and WPA[2] key handshaking and the like can probably analyze it and find where to point fingers.
I do most of my networking work on Macs, so I can't walk you through getting 802.11 monitor mode packet traces on other platforms, but just in case you have a Snow Leopard (Mac OS X v10.6) box around, you can do:
...to do an 802.11 monitor mode capture, via en1, which is typically the built-in AirPort card on most Macs, on channel 1. Modify that if your AirPort card is not en1, or if your AP is not on channel 1.
Or you can do:
(The
-c1
argument to the airport
tool puts in the interface on channel 1; modify that to the channel your AP is on.)Or you can run Wireshark, tshark, etc., but on the Mac you'll still need to use the
airport
command to set the channel and to force a disassociation.SpiffSpiff
Are you certain the firewall on this system is disabled? I've seen this behavior in Windows 7 when it isn't. Otherwise, you could check your arp tables with
arp -a
to see if you have an entry for 192.168.1.2 at all.EDIT:
Well, the arp output isn't listing an entry for 192.168.1.2, so your system doesn't appear to even be attempting to contact it. Is there a VPN or other security software involved here? Can you show the output of
ipconfig /all
?EDIT2:
Well, I was hoping that
ipconfig
shouted out something obviously broken, but it doesn't. Can you ping other hosts on the network? Try 192.168.1.1. How about other hosts in the world? My favorite to ping in 4.2.2.2.EDIT3:
Ok, lets look at things from the other side. Can you do a ping from 192.168.1.2 to 192.168.1.7, then get the results of
arp -a
, ipconfig /all
, and route print
on that system?EDIT4:
As one of the other posters suggests, you should also check your wireless router or access point to make sure it will allow connectivity between clients.
Good luck,
--jed
Jed DanielsJed Daniels
It's possible your wireless router is not allowing communication between clients. It's common for wireless routers to deny communication between hosts that are connected to it via the WLAN interface. Some wireless routers have options in their setup program to allow/deny communication between clients.
goedsongoedson
I had the same problem today on a NetGear router.
I found out that - God knows why and when - in the Advanced Wireless Settings page (down in the left menu bar, name translated from Italian) the topmost check box WPS Enabled was flagged.
I think I've never actually set that on purpose and anyway I don't think I need it, standing its meaning as per Netgear Support page 'What is Wi-Fi Protected Setup (WPS) or NETGEAR's Push 'n' Connect?'.
And of course, after clearing that check and saving changes, the ping was working back again. More than that, my laptop's Windows 7 could access again shared folders on the other laptop's Windows 7. That was the main issue that caused this research.
BTW - following @goedson suggestion - it's worth to mention that the router has a so-called PC Isolation feature, which prevents machines on the LAN to see each other. This was turned off since the beginning, I've played with it and anyway it did not make any change.
superjossuperjos
AblueAblue
protected by Community♦Feb 5 '14 at 14:28
Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
Would you like to answer one of these unanswered questions instead?