Bridged to wifi failure

[Maarten Hoes]

Im having an issue where my Guest VM's lost the ability to connect to the default gateway or beyond, when using a bridged to wifi adapter. (NAT still works as expected). I can access (tried ping) to other guest's on the the same (bridged) network, as well as the host OS on the same network. This used to work, but stopped at some point in time for unknown reasons.

I can reproduce it with VirtualBox 4.3.28, 4.3.30 and 5.0 (havent tried other releases). The guest OS is CentOS 7 in all cases. My host is Windows 8.1.

NB: After some troubleshooting, including a manual install of a debug build of 5.0 (r101573), I am now at a point with a regular 5.0 install where I can create new guest vm's with a bridged to wifi adapter that works as expected, while the older guest vm's bridged to wifi adapter still fail.

Also, see these two threads on the mailing list for more details :

https://www.virtualbox.org/pipermail/vbox-dev/2015-July/013335.html

https://www.virtualbox.org/pipermail/vbox-dev/2015-August/013366.html

[Maarten Hoes]

Two (tar gzip) guest configuration files: 'working.vbox' of a guest where bridged to wifi works, and 'failing.vbox' of a guest where bridged to wifi fails.

[Valery Ushakov]

Have you tried to rule out problems with the "old" guest configuration?

[Maarten Hoes]

Well it looks like I have found the root cause. On my ISP's wifi modem/router, there is a setting called 'DHCP Binding'. This can be used to make sure that a certain MAC always gets the same IP address assigned through DHCP. (essentially creating a DHCP scope of 1 single IP and 1 single MAC).

When I enable this for a bridged host, reaching the default gateway becomes impossible. I verified the MAC both in the VM settings as in the guest os, and made sure that they match the 'DHCP Binding' settings on the modem/router. As soon as I remove the entry from the modem/router and restart the guest, networking resumes as expected.

I had this setting enabled for the 'old' VM's, but not for the newly created ones; which explains the difference in behavior.

Now what I dont understand is why such a setting should/does break bridged to wifi networking - especially when at the same time NAT does work as expected with that setting enabled.

[Valery Ushakov]

Ah, that explains it.

When a VM is "bridged" to wifi, its packets are sent out with host's MAC as their source address (and we demultiplex packets with host's MAC as destination to host or to VMs based on the IP address).

We do preserve guest's MAC in DHCP client id, so that the DHCP server knows it's a different client, not the host. We also request the DHCP reply to be broadcast.

Some DHCP servers in home wifi routers are buggy and are confused by the fact that DHCP request comes with one MAC address as a source and a different address as a client ID, ignore the broadcast flag and just send unicast reply to the client address, which never reaches the guest, obviously. One of my routers is like that (but if I use static IP, it does work).

When your router implements MAC/IP binding it may similarly be confused by the src MAC vs. client MAC in DHCP.

[Maarten Hoes]

Thanks for taking the time to explain.

Well could you please close this ticket, then ? It seems I dont have the proper credentials to close this report.

Thanks again.

[Valery Ushakov]

Not a bug.