host only networking not working

[kumarshiv]

hello friends,

I had a perfectly working virtualbox environment with host only networking on my mac.

I applied the latest OS X patches this morning (at OS X 10.9.5 (13F34) now), rebooted the OS and bam, the host only networking stopped working. I am out of ideas atm and am looking at this community for help:

Setup:

OSX vboxnet0 adapter address 192.168.56.1, DHCP server enabled, scope 192.168.56.100-200, netmask 255.255.255.0
VM1, Ubuntu 14.04 LTS (was working before), Host Only Adapter configured, tried both para-virtual adapter and PC-ENET III. The VM does pick up the address of 192.168.56.100
VM2, also Ubuntu 14.04 LTS, same config as above, picks up an address of 192.168.56.101
OS X Version: OS X 10.9.5 (13F34) (no further updates available)
Virtual Box Version: 4.3.16r95972 (no further updates available)

Things I've tried:

* deleting and recreating the host only adapter vboxnet0 on the host OS X
* ping 192.168.56.1 on the OS X host, it works
* ping 192.168.56.100 and 101 from within the VMs that works too
* ping from 192.168.56.100 (VM1) to 192.168.56.102 (VM2) and vice versa - that works too ...
* routing table on the VMs look good, i.e. 192.168.56.0/24 network points to the local adapter eth0
* Checked Firewall on the OS X host, it is turned off.
* Read several other posts that indicate DHCP server is off etc., that isn't the case, since the VMs does pick up DHCP assigned IPs and the VMs can ping each other ..

I'm lost and confused at this time ?!?, I'd appreciate any other things to check. TIA.

[kumarshiv]

SOLVED by itself. I swear to god I didn't do anything. A wise man once told me once that what goes away unexpectedly will come back unexpectedly. I'm starting the countdown for that day, until then

[kumarshiv]

and it's back. I had to reboot the laptop today and now I can't ping again from the host Mac OS X to the VM, they both are present on the host only network, a 2nd interface on the VM takes it to the internet, VM network is fine, it can ping google.com etc., laptop OS X networking is fine, it can ping outside like google.com as well as the "host only network" IP, the one that the host and the VMs share - and so the mystery deepens .... looking for any ideas/suggestions to try. TIA.

[gyrovague]

Mostly a "me too" post, but maybe with some new info that is useful to somebody debugging this. My host is OSX 10.9.5, and has not changed in months. I have two Linux VMs, one is Arch and one is Sabayon, neither have had updates recently. My host-only networking also seems to randomly stop working sometimes.

My vboxnet0 on host has IP 192.168.56.1, and the two VMs have 192.168.56.101 and .102 (obtained via DHCP from the builtin host-only networking DHCP server in Virtualbox). Doing "arp -n", I noticed on the VMs that the MAC address shown for 192.168.56.1 did not match the address shown on the host when doing "ifconfig vboxnet0". For example, I was seeing the following on the guest:

Code: Select all

# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.56.1             ether   08:00:27:db:14:fd   C                     eth1

but on host:

Code: Select all

$ ifconfig vboxnet0
vboxnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether 0a:00:27:00:00:00
	inet 192.168.56.1 netmask 0xffffff00 broadcast 192.168.56.255

I therefore tried the following in the guest:

Code: Select all

# arp -s 192.168.56.1 0a:00:27:00:00:00

et voila! It works:

Code: Select all

# ping 192.168.56.1
PING 192.168.56.1 (192.168.56.1) 56(84) bytes of data.
64 bytes from 192.168.56.1: icmp_seq=1 ttl=64 time=0.614 ms

I can only surmise that something is going wrong with the ARP request from VM or the ARP reply from host. Given that two completely different VMs with different Linux kernels (and different distros) are experiencing this, I'd guess it's more likely the ARP reply from host (via some Virtualbox code no doubt) is somehow wrong. Interestingly though, if I delete the arp entry in VM:

Code: Select all

# arp -d 192.168.56.1
# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.56.1                     (incomplete)                              eth1

then ping again (which of course triggers a new ARP first), the ping works, and the arp cache is now correct (by itself this time, no manual entries added):

Code: Select all

# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.56.1             ether   0a:00:27:00:00:00   C                     eth1

This also was not fully repeatable, so I ran tcpdump on the VM after deleting the arp cache entry again, and discovered that the ARP request receives TWO replies, and sometimes the correct reply is first and sometimes the incorrect reply is first...

Code: Select all

15:40:40.074888 ARP, Request who-has 192.168.56.1 tell 192.168.56.102, length 28
15:40:40.076072 ARP, Reply 192.168.56.1 is-at 08:00:27:db:14:fd (oui Unknown), length 46
15:40:40.076108 ARP, Reply 192.168.56.1 is-at 0a:00:27:00:00:00 (oui Unknown), length 28

I tried tcpdump on the host (OSX) on the vboxnet0 interface, but that only seems to show the ARP requests, the replies aren't shown there at all, presumably the replies are generated internally in virtualbox somewhere. Since the host-only networking is supposed to be only between the guest/s and the host, presumably the ARP request isn't going anywhere else on the network, and therefore presumably nothing else will send an ARP reply, besides which there is nothing else on my host or LAN which uses the 192.168.56.* subnet.

As with kumarshiv I've also tried deleting the host-only network in virtualbox and creating a new one, to no avail. I've tried restarting Virtualbox box too, to no avail. I'm using Virtualbox 4.3.20 r96996 (recently updated in order to try to solve this issue, to no avail, i.e. the previous version did the same).

[gyrovague]

I found this on google:
(ticket 10593 on virtualbox dot org, cannot yet post link because "You must be a member for 1 days and have 1 posts before you can post urls")
which I thought sounded relevant... I checked, and my DHCP server setting in virtualbox host only networking was indeed also set to 192.168.56.1, therefore clashing (the meaning of the setting apparently hadn't been obvious to me when I first configured it, I think it should be better described in the UI). Interestingly, I tried then disabling the host only networking DHCP server setting, and still see the TWO ARP replies mentioned above... So it seemed like changing the setting didn't really "stick"...

I then figured out how to do it on the command line on my host:

Code: Select all

VBoxManage dhcpserver remove --ifname vboxnet0
VBoxManage dhcpserver add --ifname vboxnet0 --ip 192.168.56.2 --netmask 255.255.255.0 --lowerip 192.168.56.150 --upperip 192.168.56.199 --enable

(I changed the range of the DHCP to additionally be able to check inside VM whether the "new" server was being used).

Above seems to have done the trick for me! I now no longer get two ARP replies, and my VM gets the correct address for 192.168.56.1 in its arp cache, and can ping the host (and host can ping the VM).

[JohnBooty]

Mostly a "me too" post, but maybe with some new info that is useful to somebody debugging this. My host is OSX 10.9.5, and has not changed in months. I have two Linux VMs, one is Arch and one is Sabayon, neither have had updates recently. My host-only networking also seems to randomly stop working sometimes.

My vboxnet0 on host has IP 192.168.56.1, and the two VMs have 192.168.56.101 and .102 (obtained via DHCP from the builtin host-only networking DHCP server in Virtualbox). Doing "arp -n", I noticed on the VMs that the MAC address shown for 192.168.56.1 did not match the address shown on the host when doing "ifconfig vboxnet0"....

Your post was a huge help to me. This issue has plagued me for months and has been the cause of much downtime for me at work. Thanks!

My issue was very similar. The only difference for me is that instead of having incorrect arp entries on the guest, I had no arp entries whatsoever. Weird. Regardless, the solution was the same - manually add the arp entries with "sudo arp -i eth1 -s 10.203.175.1 0a:00:27:00:00:00"

If anybody else is having this issue, note the additional "-i eth1" in my solution. All that does is explicitly tell arp which interface we're talking about. If your guest OS has multiple network adapters (mine did) you may need to do that.

[gyrovague]

Glad to know my lengthy post at least helped one other random person on the planet. I'm now using Virtualbox 4.3.20 r96996 on OSX (latest available), and I see they still haven't improved the host only networking UI to avoid the DHCP clash. I guess the Oracle Virtualbox developers don't actually read these forums. It seems like it should be a very very easy fix.

For posterity, here is the ticket URL I was previously not allowed to post here: https://www.virtualbox.org/ticket/10593

That is also over 3 years old, with no resolution yet.

[sanjeevk]

Running mac osx version 10.10.2 and virtualbox version 4.3.20.r96996

on my mac osx:
vboxnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 0a:00:27:00:00:00
inet 192.168.56.1 netmask 0xffffff00 broadcast 192.168.56.255

Guest VM is OEL6.6 and configured 2 NICs

Adapter1: Host-only Adapter vboxnet0
Adapter2: NAT

on my guestVM ifconfig returns:
eth0-> 192.168.56.198 Mask: 255.255.255.0
eth1-> 10.0.3.15 Mask: 255.255.255.0

I ran the VBoxManage command from above post as there was a conflict on vboxnet0 ip: 192.168.56.1 and VirtualBox DHCP address ip also.

When I run arp command on guest VM now it does not return anything.

From my MAC OS X -->> terminal --> ping 192.168.56.198 (VM ip address) -- does not WORK. This has been case before also.


Any help appreciated.

Thank you
Sanjeev

[sanjeevk]

One more thing i noticed is when I connect to my work cisco vpn network -- ping is not working from macosx to guest VM -- otherwise it is working fine.

[Alexual]

This helped me too (4.3.30 on Mac host). Seems like deleting then creating the Host-Only adaptor on the GUI leaves something behind (or does not stick).

Once I deleted the Host Only adaptor (in GUI) and re-created via the CLI (/Applications/VirtualBox.app/Contents/MacOS/), the CentOS guest machine (eth1) was able to obtain an IP address from the Host Only adaptor. To be clear, after deleting the adaptor:

Code: Select all

./VBoxManage hostonlyif create
./VBoxManage dhcpserver add --ifname vboxnet0 --ip 192.168.56.2 --netmask 255.255.255.0 --lowerip 192.168.56.150 --upperip 192.168.56.199 --enable

I had originally cloned this machine, so thought a MAC address refresh might help (it didn't).

This saved me some time. Thank you.

[plapla]

Hello,

A "me to post" : I could make it work again by using ifdown/ifup on both VMs.

Setup :
- Host Win7 with VirtualBox 5.0.6 r 103037
Adapter1: NAT
Adapter2: Host-only Adapter vboxnet0
- guest VMs : Ubuntu 14.04LTS

VM1 :
eth1-> 192.168.56.5/255.255.255.0
VM2 :
eth1-> 192.168.56.6/255.255.255.0

What I tried : On both VMs,
# ifdown eth1
# ifup -v eth1

then the network configuration was back to normal : only one reply to ping, arp is correct, …

Thanks’ for your valuable comment.

[Soundar]

In my case it's working in the office network and not working in the home network. After thinking it through i figured out that my home network IP range is 192.168.68.1 --- 254. Whereas the network mask is 255.255.255.0.

This causes collision with the host only network 192.168.56.1. So i deleted the host only adapter, recreated one another with IP 177.177.177.1 and rebooted the VM. Now it works without any issues.

[socratis]

'Soundar',
It would be best if you didn't wake up a four-year old thread, soon to be locked and returned back to zombie-land...

range is 192.168.68.1 --- 254. Whereas the network mask is 255.255.255.0 ... This causes collision with the host only network 192.168.56.1

No it doesn't, that's what the network mask of 255.255.255.0 mean, that you can have a different network if you modify any of the A, B, C on a A.B.C.(1-254) with no conflict.

recreated one another with IP 177.177.177.1

Oh no, you didn't! Those are real IPs, not private ones, somewhere in Recife, Pernambuco, Brazil!