How-to: VirtualBox Bridged Mode over Wireless Networking (2021)

Continuing our VirtualBox series, here's how-to: VirtualBox Networking Bridged Mode updated for 2021. This is taken from The VirtualBox Networking Primer in paperback and Kindle Ebook formats on Amazon as well as ebooks on Kobo and Apple Books.

Let's take a look at VirtualBox Networking Modes moving on to Bridged Mode over Wireless.

Bridged Mode over Wireless Networking

Let’s say this up front: VirtualBox connections using Bridged mode via wireless are possible, but not guaranteed.

Bridged mode and Host wireless connections don't always play well together. Bridged networking sits outside the common WLAN specification. Where a driver or network device adheres strictly to the WLAN standard, the standard doesn't allow multiple devices to share a client link. Many WLAN device vendors do not implement the official standard as-written; therefore, many device combinations can function under the bridging work-around that VirtualBox has.

Under virtualisation, the Guest shares the MAC address of the Host while the Hypervisor (VMware, KVM and not just VirtualBox) attempts a sort of MAC-to-NAT translation based on IP addresses of the two machines. As such, bridging to wireless is not really bridging. This in itself may or may not work. The particular combination of physical router, access point, wireless and drivers may allow it – or not.

Bridged networking needs the device driver and the VirtualBox filter driver to work together to allow the Host and Guest to share the device. When it fails, this is not the fault of VirtualBox, it is the strict implementation of WLAN standards in the vendor hardware or drivers; don’t blame the messenger.

If that isn’t enough, there is an extra layer of networking protocols including authentication which aren’t covered in the normal wireless adapter software drivers on any platform. Even if you can persuade the hardware, drivers and VirtualBox to bridge the connection, the wireless access point may still refuse to connect on the basis that no credentials can be supplied; there simply isn’t an authentication layer in the network bridge.

In the next example, let’s try to connect to the wireless LAN using Attached to: Bridged and the interface name wlp2so which is the one that VirtualBox can see as available and boot the virtual machine.

Figure 21: Bridged Network adapter on Wireless

With the Guest running, let’s see the IP address assigned and ping an external address to check the connection:

$ ip add

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 08:00:27:7c:00:d5 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::a00:27ff:fe7c:d5/64 scope link 
       valid_lft forever preferred_lft forever
robin@debian-server:~$ ping 8.8.8.8

connect: Network is unreachable

As you can see, network adapter #2 is listed as eth0 – an Ethernet adapter. The Guests sees only virtualized hardware, not the real hardware that sits in the Host PC. The Guest requests an IP address which the Host's Wi-Fi adapter passes to the router. The router is operating with WPA/PS2 authentication. The router’s ‘who goes there’ challenge cannot be answered, so it assigns no IPv4 address.

What to do?

There are a couple of options left with the potential for happy endings.

Bridged networking can work with a Wi-Fi adapter in some cases where it can be configured in Promiscuous Mode. More on this follows in the next section. However Promiscuous Mode is not supported on many Wi-Fi adapters, including, after testing it, the one in our VirtualBox Host.

 

Comments