Bridging 2 Guest Adapters

[HarryMan]

I want to know if virtualbox 6.1.x supports bridging 2 guest adapters. To avoid confusion, I am explicitly stating that:

1. I am not referring to virtualbox's "bridged networking" mode whereby a guest can talk to an external network via the host.
2. The system hosting virtualbox is not involved with this at all (other than to run vbox and its network drivers, of course; this is understood)
3. As the admin inside the guest, I want to bridge 2 adapters which have been defined for said guest (defined, i.e., using either vboxmanage or the vbox gui).
4. I do not want to bridge these adapters from the outside (i.e., on the system hosting virtualbox), even if that were possible.

As a long-time virtualbox user, I understand there may be limitations to various aspects of the product. I have read through the networking section of the docs several times and I do not see anything called "limitations" except for certain aspects of the modes previously mentioned. So far, I have not noted limitations for the general use of guest adapters.

I think it is somewhat reasonable to expect that virtualbox guest adapters will work more or less the way they would work on physical hardware. But there is always the chance I am trying to do something that simply is not supported by the product. Before I proceed any further, I want to make sure that I am not chasing an unrealistic goal.

Thank you for your patient understanding and constructive assistance.

[HarryMan]

I have tried this using the linux "bridge" command. I create the bridge, give it a unique MAC, and add the adapters (links) I want to connect. Finally, I assign the bridge an address. I performed all of these commands as root inside the VM.

To keep this simple, let's say I have a VM running devuan with 3 interfaces. eth0 -- connects to my host or whatever else. eth1 -- connects to a few hosts on intnet1 (a vbox internal network perhaps). eth2 -- connects to a host or two on intnet2 (another vbox network, maybe intnet also). Assume all of the machines on both links of have fixed (not dhcp) addresses on 192.168.150.0/24.

The trouble I am running into is that the VM can talk to systems on one link, but not to systems on the other link. My expectation, if I understand (ordinary, not vbox) bridging correctly, is that any system connected to either one of the links I added to the bridge should be able to talk to the VM, and to each other. I also "get" that neither the VM nor any of the systems on those links will be able to talk to the outside (host or Internet) necessarily unless I provide additional networking to support that. For this simple scenario, let's not worry about this. I just want to know if the scenario which I am describing should work.

[scottgus1]

This sounds like an interesting project! I'm very interested to see if you can pull it off, as I also have wanted to try an experiment with a VM acting as a network switch for whatever network cards are connected to it, and I have been unable to make it happen. I have blamed this mostly on my woeful lack of Linux knowledge, and partly on the excellent knowledge of internet tutorial makers, who seem to forget a basic step in the tutorial, which leaves me with a switch that doesn't switch.

As best as I ever heard, the virtualized network cards act just like the physical cards in real life. So you ought to be able to use OS commands on the network cards in the VM same as you could on a physical PC.

See Virtualbox Networks: In Pictures. I'd recommend trying this with unique Internal networks without any DHCP servers for the "cables" between the switch VM and the other VMs. For example, the switch VM has four cards in it, three cards connected to Intnet1, Intnet2, and Intnet3, and the fourth unconnected. Three small WMs as 'clients', each with one network card, each connected to one of the three Intnet# networks. Try the Linux bridge command in the switch VM on all four cards, see if the three client VMs can set up comms between each other using static IP addresses. Then set the IP's to dynamic and try adding a Host-Only network with an active DHCP server to the fourth card in the switch, and see if Host-Only can hand out IP addresses to the VMs.

If you can pull off making the switch work, please tell me how. I'd really like to try it too.

[HarryMan]

@scottgus1, thank you for your response. The scenario I described in my second post is pretty much the same as the one you propose. In fact, anyone trying to examine if/how this could work might try it themselves.

Yes, I agree that vbox adapters *should* work like ordinary, real-life adapters. I think that's the point. The question I have is whether the vbox devs intended for that to *always* be the case, or if there might be limitations. IOW, whether behavior would always reflect real-life behavior of internet devices.

I am currently running several https://openwrt.org/ routers in virtualbox. openwrt supports this, and so far, it works. The one thing I can't seem to get openwrt to do, though, is this guest-side bridging.

With regard to your dream of running a switch in virtualbox, you might look at https://www.openvswitch.org/ as a possibility. I've looked at it, but have not yet figured out exactly how to use it in a virtualbox network scheme.

[fth0]

Can you describe the setup in more detail? Perhaps with a picture (can be ASCII) containing all network participants? Potential topics that come to mind are broadcasts, promiscuous mode, loops and shortcuts.

[HarryMan]

fth0: I thought I had described the scenario in about as much detail as I can, above. Maybe re-read my posts and see if you still have questions.

[fth0]

I've read your descriptions before, and again now. To analyze what could work and what not, I'd suggest to concentrate on a dedicated setup with the necessary and sufficient components, that's why I asked for more details, and suggested common pitfalls to consider. Also, I've been too lazy to invest an hour to write a detailed answer. I'll try and give some pointers:

To keep this simple, let's say I have a VM running devuan with 3 interfaces. eth0 -- connects to my host or whatever else. eth1 -- connects to a few hosts on intnet1 (a vbox internal network perhaps). eth2 -- connects to a host or two on intnet2 (another vbox network, maybe intnet also). Assume all of the machines on both links of have fixed (not dhcp) addresses on 192.168.150.0/24.

I assume that your "hosts on intnet1" are supposed to be other VirtualBox VMs, intnet1 and intnet2 are VirtualBox Internal Networks, and none of the other VMs are connected to both intnet1 and intnet2? This ist the "loop and shortcuts" aspect.

The trouble I am running into is that the VM can talk to systems on one link, but not to systems on the other link. My expectation, if I understand (ordinary, not vbox) bridging correctly, is that any system connected to either one of the links I added to the bridge should be able to talk to the VM, and to each other.

To "talk to" is a broad term and includes different protocols. The first one to consider is ARP and uses broadcasts on the Ethernet layer. Then there are the static IP address assignments and routing tables in the different OSes involved, followed by e.g. ICMP, DNS and SSH/HTTP(S) communication. This is where "broadcasts and promiscuous mode" come into play.

I just want to know if the scenario which I am describing should work.

Generally speaking, a correctly setup scenario should work, but I cannot tell if it does. While I do have practical experience with low-level networking protocol details, especially from setups not involving VirtualBox, I don't have practical experience with the VirtualBox scenario you're trying to set up. But I could help with guiding further analysis on a dedicated setup.

[HarryMan]

I assume that your "hosts on intnet1" are supposed to be other VirtualBox VMs, intnet1 and intnet2 are VirtualBox Internal Networks, and none of the other VMs are connected to both intnet1 and intnet2? This ist the "loop and shortcuts" aspect.

Yes, to confirm this: When I refer to "intnet1" and "intnet2" these are virtualbox internal networks, and they are entirely disparate and unconnected to each other, aside from the VM in question where I was trying to do this bridging.

When I said the VM could talk to one intnet and not the other, I just meant there was no apparent connectivity. I should probably set up vbox network debugging (I've done this before for other issues) on the two interfaces on the VM to see if any packets are reaching them.

I'd recommend trying this with unique Internal networks without any DHCP servers for the "cables" between the switch VM and the other VMs. For example, the switch VM has four cards in it, three cards connected to Intnet1, Intnet2, and Intnet3, and the fourth unconnected. Three small WMs as 'clients', each with one network card, each connected to one of the three Intnet# networks. Try the Linux bridge command in the switch VM on all four cards, see if the three client VMs can set up comms between each other using static IP addresses. Then set the IP's to dynamic and try adding a Host-Only network with an active DHCP server to the fourth card in the switch, and see if Host-Only can hand out IP addresses to the VMs.

That was exactly what I had in mind, although I think that 2 networks coming off the switch VM should be ample enough to demonstrate it. OTOH, I've got an underutilized test box and I probably should give that a go. Given you have been so patient and helpful, I will attempt this soon and post back here.

[fth0]

When I said the VM could talk to one intnet and not the other, I just meant there was no apparent connectivity. I should probably set up vbox network debugging (I've done this before for other issues) on the two interfaces on the VM to see if any packets are reaching them.

To "talk to" is a broad term and includes different protocols. The first one to consider is ARP and uses broadcasts on the Ethernet layer.

I'd suggest to try the following: On the host, use the VBoxManage modifyvm "VM name" --nictrace... options to capture the network traffic on all adapters which are connected to the Linux bridge inside the VM. Then ping a non-existing local IP address and check if the ARP request is broadcast to all internal networks.

[HarryMan]

I'd suggest to try the following: On the host, use the VBoxManage modifyvm "VM name" --nictrace... options to capture the network traffic on all adapters which are connected to the Linux bridge inside the VM. Then ping a non-existing local IP address and check if the ARP request is broadcast to all internal networks.

Yes that's what I meant:

I should probably set up vbox network debugging (I've done this before for other issues) on the two interfaces on the VM to see if any packets are reaching them.

Sorry if that was not clear. You call it "tracing", whereas I referred to it as "debugging." I guess "tracing" is more apt.

[fth0]

I didn't want to clarify any potential misunderstanding, I just wanted to hint what would be the first detail to debug or trace from my POV. Everything's fine.