Assume the following Situations:
- Gateway IP :
10.0.0.60 - Host IP (Win7) :
10.0.0.81 - Guest 1 on this Host (VMWare-Linux-Kali) :
10.0.0.16 - Guest 2 on this Host (VMWare-Win7) :
10.0.0.27 - Gateway is a Kerio server.
The Problem:
I can't ping the gateway from Kali-Linux virtual machine, while I can ping it from both Host and Win7 virtual machine!
Configuration:
- All the firewalls for Host and guests are off.
- Guests can successfully ping each other and also ping the Host!
- Host can ping both guests successfully!
- Network Adabpter settings for both guests are equal and the only difference is their IP.
- Network adapters of virtual machines are bridged with the host network adapter.
What am I did so far?
I replaced Kali-linux guest IP address with Win7 guest IP address (and vice-versa). Well, nothing changed!
I tried other operation systems as guest. For Ubuntu and Backtrack I can't ping the Gateway too, but for Win7 and Win XP it is ok.
I run Wireshark on my host and monitor the traffic. Well, I can see ICMP request packets for both Linux guests and windows guests, but the reply from Gateway are for Windows guest only.
Unstable solution:
In the past when I face with this problem, manipulating the route table on Linux virtual machine was solved the issue (50%-50%), but now it doesn't work any more!
Settings:
My Host:
C:\Users\asdf.IT>ipconfig -all
Windows IP Configuration Host Name . . . . . . . . . . . . : asdf-PC Primary Dns Suffix . . . . . . . : it.com Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : it.com
Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller Physical Address. . . . . . . . . : 08-60-6E-70-4C-E4 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::6079:96ba:2ea2:18e9%11(Preferred) IPv4 Address. . . . . . . . . . . : 10.0.0.81(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 10.0.0.60 DHCPv6 IAID . . . . . . . . . . . : 235429998 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-B7-B0-8E-08-60-6E-70-4C-E4 DNS Servers . . . . . . . . . . . : 10.0.0.10 8.8.4.4 NetBIOS over Tcpip. . . . . . . . : Enabled
Ethernet adapter VMware Network Adapter VMnet1: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet
1 Physical Address. . . . . . . . . : 00-50-56-C0-00-01 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::45cc:c483:1d0a:a9a%17(Preferred) IPv4 Address. . . . . . . . . . . : 192.168.227.1(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : DHCPv6 IAID . . . . . . . . . . . : 218124374 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-B7-B0-8E-08-60-6E-70-4C-E4 DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1 NetBIOS over Tcpip. . . . . . . . : Enabled
Ethernet adapter VMware Network Adapter VMnet8: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet
8 Physical Address. . . . . . . . . : 00-50-56-C0-00-08 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::19cc:79f0:bc05:ce97%18(Preferred) IPv4 Address. . . . . . . . . . . : 192.168.153.1(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : DHCPv6 IAID . . . . . . . . . . . : 251678806 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-B7-B0-8E-08-60-6E-70-4C-E4 DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1 NetBIOS over Tcpip. . . . . . . . : Enabled
Tunnel adapter isatap.{1FD7A0A9-BE6F-44F9-8BA7-E7E0043D4B36}: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft ISATAP Adapter #3 Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes
Tunnel adapter isatap.{41D1949E-CADB-47E2-BBDC-F907E48DBA03}: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft ISATAP Adapter #4 Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : YesDoes anyone have any idea what is the origin of this problem?
2 Answers
Your routing table is correct, actually it is identical to mine.
But you state:
I run Wireshark on my host and monitor the traffic. Well, I can see ICMP request packets for both Linux guests and windows guests, but the reply from Gateway are for Windows guest only.
This means your gateway is responding differently to the two ping packets. The best way to proceed is to capture both packets and to compare them. Since you are running wireshark, listen on the Host outbound interface, restrict your capture to the icmp protocol and to destination 10.0.60.0, ping once only from host1 nd host2, save the 2 packets to a file, study what is different between them.
The difference between the two packets is what is triggering the different gateway behavior. If, at the end, the only difference is the source IP address, then it means there is a problem with your kali Ip address. If it is a static address make sure it is outside the DHCP range. If not you may try restarting gateway, host and VMs to ensure the release of the DHCP leases, in case of conflict with previously assigned addresses.
3I had an almost identical problem (Google brought me here) but in my case the issue was the the VM configuration had somehow changed from Bridged (assigned to it's own NIC) to NAT, hence the VM kept thinking it had an IP address allocated by VMWare's virtual bridge, despite me having modified /etc/networking/interfaces and restarted the network service....
In hindsight, I can't think how the network settings could change within VMWare, so I'm more inclined to think it was my mistake, but I could have sworn I set the VM to 'bridged' before starting up the Kali VMDK....