virtualbox.org

Hello forum,
I want to create a "private network" of multiple Linux guests on a Windows host.
The guests must communicate with themselves and with an external private network, that is inaccessible to the host, via a single physical connection.
Connectivity to the "external private network" is set up via a USB ethernet dongle, which a dedicated "bridging machine" sets up.
Requirements call for the guests to communicate with the private external network in a bridging fashion and not via a router.

So:
I connected all the guests (including the bridging-machine) to a VirtualBox internal network.
In the "bridging machine", I linux-bridged the USB-ethernet-dongle and the VirtualBox internal-network interface.

Problem:
For some reason, the other guests receive only broadcast messages coming via the bridging-machine over the internal-network.
I suspect the internal-network implementation drops packets originating from non-participating MACs (the incoming packet has a MAC of .

There are no iptables or ebtables filter. I am using new Lubuntu 16.04 and 16.10 machines. It does not matter if I assign network address to the bridge in the bridging-machine or not...

Any ideas about the problem, or how to fix it? Thanks!

I would not have used an internal virtual network for that. I would bridge the vms to a physical NIC in the host and connect that NIC to your bridging device.

Thanks, I wanted to avoid the possibility of the host to access that interface (from security perspective). With USB redirection, the host is unaware there's a network device attached. Host bridging will definitely be my fallback solution.

As for the internal network not passing packets coming from a different interface - is that a bug, by design, or a misconfiguration?

Bill's method (use Virtualbox Bridged to connect all the guests to one physical Ethernet adapter, then connect the special network to that physical Ethernet adapter too) works to get the private test guests connected to the real world.

To isolate the host from that virtual/physical private network, you can do this if your host PC is Windows (there may be similar possibilities for Mac & Linux hosts):

Open the Control Panel, then Network and Sharing Center. On the left click "Change Adapter Settings". Right-click the adapter you wish to reserve for the guest and choose Properties. In the middle of the Properties popup is the box "This connection uses the following items". These are the "bindings" that connect services to the network adapter. On the NIC to be reserved for the guest, uncheck all the bindings that don't mention Virtualbox. Then click OK. Now the host can't use that card for network access, but Virtualbox Bridged can.

If you wish to make sure you won't Bridge to any other NIC by accident, open all the other physical NICs' properties and uncheck just the Virtualbox bindings on those physical NICs. (Don't do this to the Virtualbox Host-Only Adapter - leave that one alone.) Now Virtualbox will be unable to Bridge to any other physical NICs besides the one set aside for the guest.

Note that Virtualbox Bridged does not always work with Wi-Fi - you should go wired on this test network. And if you don't have two physical Ethernet adapters on your host PC you should be able to use that USB Ethernet dongle: remove it from the "bridging" guest and delete the USB filter so Virtualbox won't capture it in that guest again. Then let the host PC use the dongle, and Bridge to that dongle with the isolation instructions above.

Re Bridging Bridged to Internal not working: Could be any number of things... Internal is meant to be, wait for it ..... internal. Maybe the developers never put full ability to connect an Internal network to another network via a guest-OS-generated bridge.

Also, the guest OS bridge may not connect to Internal right, or it may have problems with the Virtualbox Bridged end of the equation.

Or two Bridges can't connect.

It would be way over my head to see where the issue lies, unless the source code and lots of time was available. (it is for Virtualbox, probably for the Linux guest OS too. Time? Not so much on this end. )

shoot-out to scottgus for your post on preventing unintended routing at the host.

I am new to virtualbox. First impression; I love it, virtualbox saved me from having to scratch servers and start over with vmware. However, my config compromised network security. My host hardware has multiple nics, formerly for failover cabled to the target vlan. I changed this and the nics now cable to client-purpose vlan. This change effectively shortcircuited vlan isolation, creating my own exhaust port. One client is running webservices and isolated to run in the DMZ, yet my virtualbox config compromised network security because the host instance became an unintended router bridging my DMZ and internal vlans. I realized this security risk at install and my solution was to block internal traffic at the firewall, and I started questioning if virtualbox was viable... Until I read this post. The risk potential of creating an inadvertent pathway between vlans continues with either an errant host change to a nic or a firewall change. If you review my post and have comments on a better way, please let me know. thank you.

~David

Sounds like you got quite a pot of spaghetti going there, Dave! What I've seen with network tools, either real devices or Virtualbox, is that there are so many places for pebcak errors to appear. Like all tools, Virtualbox can be misused.

I don't think there are any network holes in Virtualbox. Being open-source, these things get found and fixed rather quickly, and the forum hasn't blown up with troubles over leakage in networks. It would blow up if there was a known problem (just think about Windows hardening, that was a doosie - and that was the fix, the problem hadn't shown up yet). Not to say it can't happen. But it hasn't yet, that I have seen.

I'd say that in essential systems like isolating DMZ computers, doublechecking your setup with local and forum experts is also essential. I have heard that in some places someone accidentally connected an Ethernet cable to the wrong port and put critical systems open to other systems or the web, and even companies that seriously ought to know better have had hacks (remember Equifax?). The key is open-sourcing: let others see your setup and pick it over / proofread it for problems.