I’ve found the solution, and it’s exactly as stupid and obvious as I was expecting.
The classroom computers were deployed using Clonezilla from an image that had the VirtualBox VM pre-configured. As a result of this, every VM had the same MAC address, which probably caused a lot of ARP collisions, since all the hosts and VMs were essentially on the same broadcast domain.
The solution was to simply randomize each VM’s MAC address. After that, ICMP, SSH, and HTTP worked as expected. Thanks for the suggestions, but it was caused by my own oversight in the end.
(edit) I got around to reading the comments just now, @maxy@piefed.social was totally correct.
I know this isn’t “selfhosting” as most people imagine it, but it is about hosting services on own hardware, hence why I’m posting in this community.
I’m supposed to help a teacher set up a networking exercise where pairs of computers are connected directly on a crossover cable and can access services (echo, HTTP, SSH, FTP) on each other. Every computer is identical: Windows 10 host, one VirtualBox VM running Linux Mint with a bridged adapter in promiscuous mode. Each host and VM has its own static link-local IP address.
The problem is, the VMs can’t talk to each other, and I don’t know why.
From one VM, I can ping itself, its host, and the remote host, but not the remote VM. Each host can ping itself, the local VM, the remote host, but not the remote VM. I’ve tried connecting both hosts to a layer-2 switch, with the same result.
Can someone point me at the one thing that I’m obviously doing wrong?
(edit) I’ve also tried to set the default gateway to the host’s, remote host’s, and remote VM’s address, but nothing changed.
Running Linux on metal isn’t an option. In the past, the classroom computers used to dual boot Windows and Ubuntu, but the Windows install got so bloated (the software too, not just Windows) that it needs the full SSD.
Sounds like a networking exercise on its own.
Do the attempted pings show up on the wire? (Switch LEDs, network card activity light.)
Does broadcast work? (Watch if it is received with
tcpdump -non both Linux VMs, and Wireshark on the Windows hosts, while doingping -b 10.0.0.255. Or trigger a broadcast ARP by ping-ing a non-existing IP in the same network. Those should go through all bridge and switch devices, independent of IPs and routing setup.)I think you need four distinct MAC addresses for this setup, are they all different?
The network card/driver is filtering received unicast by MAC. I’m sure something should set up the filters correctly, but maybe it went wrong, or there is a bug in the driver. Wireshark on Windows should be able to enable promiscuous mode, which disables the filter.
Side note: I don’t think you need a crossover cable. Auto-crossover should just work these days.
At work I map a USB Ethernet device into my Linux VM when I do anything networking, exactly to avoid those kind of “is it Windows?” questions. Also, I can then check the Ethernet link at the lowest level using Linux tools like ip link or mii-tool or ethtool.
I’m using VMWare for this, which I cannot recommend any more. (It used to be good for this, but gut much worse in recent years.) I think vanilla VirtualBox doesn’t allow to map USB devices.
I think you need four distinct MAC addresses for this setup, are they all different?
We have a winner!
The classroom computers were mass-deployed using Clonezilla, from a disk image that already had the VM pre-configured. As a result, every VM had the same MAC address. Bridged networking put both hosts and both VMs in the same broadcast domain, which caused collisions in the ARP tables. I randomized the MAC address of one VM and everything suddenly started working.
It’s never been an issue since we’ve never needed to use anything other than the default NAT adapter, so I’ve never even questioned it. I found the solution after plugging the computers directly into an access switch without success, and cross-checking
show mac address-tablewith the MAC reported by the VMs revealed that they were identical.Thanks for the follow-up. Of course you would have some kind of mass-deployment, it didn’t think of that. I thought you’d maybe copy the Windows MAC to Linux, but… then you’d remember doing that.
Next up, they will also all have the same ssh host key ;-) (Which may be an advantage actually, but still confusing.) Those are the kind of problems cloud-init is solving, I guess.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters ARP Address Resolution Protocol, translates IPs to MAC addresses IP Internet Protocol NAT Network Address Translation
3 acronyms in this thread; the most compressed thread commented on today has 8 acronyms.
[Thread #104 for this comm, first seen 19th Feb 2026, 11:31] [FAQ] [Full list] [Contact] [Source code]
That looks like it should work. Just a couple of thoughts: The default gateway is irrelevant. That’s only where the OS sends packets that don’t match the netmask. Since these addresses all lie within the same /24 range, the default gateway will never be used. It wouldn’t hurt to check the ARP tables of each OS to see whether the VM MACs ever show up on the remote host or VM. Are the two hosts connected with a cable, or via WiFi? If the latter, VirtualBox has to do some software trickery to make bridging work, and I can imagine that perhaps some WiFi devices wouldn’t play nice.
You mentioned that you can’t ping the remote VM. Have you checked if the remote VMs IP is reachable? Is it in the ARP table? Check with
arp -aThe issue was ARP-related after all. Since all computers were cloned from the same image, the VMs ended up having the same MAC address, which caused collisions.
I checked
ip neighbour(it also shows the ARP table, so I assume they’re identical), and it showed REACHABLE and STALE for addresses I could ping, but FAILED for the remote VM’s address. I will checkarp -awhen I get the chance, though.
This is going to sound stupid. Have you checked both the host and VM firewalls are allowing the traffic?
To assist in troubleshooting you can install Wireshark to see what traffic is hitting the NIC. If you see the the traffic in Wireshark then the sending is working but the host or VM is not receiving.
@rtxn I’m no expert in networking with VirtualBox, but did you already had a look into the manual?
https://www.virtualbox.org/manual/ch06.html#network_udp_tunnelI’ll give it a try tomorrow, thanks.
Although I’d still prefer to know why the VMs won’t talk over simple Ethernet.
@rtxn Maybe you find the reason in the chapter for Bridged Networking.
https://www.virtualbox.org/manual/ch06.html#network_bridgedWith bridged networking, Oracle VM VirtualBox uses a device driver on your host system that filters data from your physical network adapter. This driver is therefore called a net filter driver. This enables Oracle VM VirtualBox to intercept data from the physical network and inject data into it, effectively creating a new network interface in software.
I’ve re-read the docs around VirtualBox bridging, and the only thing that I think could possibly cause this (though it shouldn’t since ping is a direct address to a specific IP/mac) is to enable Promiscuous mode (as cappucino mentioned).
This shouldn’t fix it in my opinion, but it may, since ICMP could be considered undirected traffic (I don’t, but I didn’t code VirtualBox).
I’ve sometimes found using trace instead of ping can sometimes work where pings would be blocked, plus trace shows exactly where it dies along the path.
Try this setup.
I’m certainly not an expert on such things but I just didn’t think bridged networks in virtual box (or docker) were intended to work that way.
The behaviour you’re seeing is exactly what i would have expected.
In docker I think the solution would be to use the “host” network adapter on the guest VM.
Try this setup.
10.0.0.1 is usually the gateway IP. Have you checked that there are no IP collisions happening?
