MAC addresses filtered by VBox bridging

[Raltar]

I am attempting to run an OpenVPN server in a Ubuntu 12.04 (server) guest machine running on a Ubuntu 12.04 (server) host via VBoxHeadless. This OpenVPN server needs to run as a layer 2 VPN (tap) which means it will place clients onto the local LAN with their own MAC addresses visible, and these clients need to be capable of two-way communication at layer 2. I have been using the bridged network adapter for the VM.

When run from within the VM, I can connect clients to this server and ping/log into the server's IP, (guest machine) but I cannot access the Host's IP or anything else on the LAN from the client. If I set up the OpenVPN server identically on the host, (Which is the same OS and otherwise identical setup) it works fine. OpenVPN requires setting up a bridge internally on the server for this kind of layer 2 tap VPN, and putting the ethernet interface into promiscuous mode. I've tried attaching the VM bridged adapter to the physical eth0 interface of the host and also to a bridged adapter on the host that was then bridged to the eth0 interface while eth0 was in promiscuous mode (similar to the setup on the guest)

I have found two other references to this problem, one with a Linux host, the other with Windows. The Windows one was ticket #8965. Both references indicate that this bug was a regression between versions 4.0.4 and 4.0.6. Since I'm using Ubuntu 12.04 and VBox 4.1.18, downgrading to VBox 4.0.4 to confirm this would be painful.

Looking at the changelog of 4.0.6, I suspect that I've found the culprit: "Host-Only & Bridged & Internal Networking: fix for processing promiscuous mode requests by VMs, defaulting to switch behaviour "

Not sure what is meant by "switch behavior" but a switch is nothing more than a many-port bridge, which will broadcast frames to all ports but the one it came in on if the MAC is not in the MAC table, will learn the source MAC of any frame and put it in the MAC table for the port it came in on, and will unicast learned MACs to the ports on which the MAC table says they reside. This may be somewhat inconsistent with being able to specify a MAC for the bridged adapter of the guest (which I have also done in this case) If the switch portion is not flooding unlearned frames out to the guest machine virtual ports and also learning new MAC entries from frames sent by those ports, then the behavior may be efficient, but it will also be incorrect for Guests with their interfaces in promiscuous mode.

This bug is closely related to #8965 and this version with the Linux host type is also referenced here: ​https://forums.virtualbox.org/viewtopic.php?f=7&t=42335&p=203067&hilit=openvpn#p203067

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.

[copec]

I am experiencing this exact issue with VirtualBox 6.0.12r133076 on Windows 10 Pro version 1903 build 18362.295

A virtual nic attached to bridged adapter with promiscuous mode set to allow all is only allowing the mac address generated for the virtual nic to be bridged and no other mac addresses.