Allow All and Allow VMs MAC filtering does not work

[dgarrod]

I am running two Ubuntu Linux Guests on a Windows 7 Host.

I've set up Internal Networking between them. This all works fine if I let VirtualBox pick and use the MACs on the virtual interfaces.

But in my case my Linux Guests set the Hardware MAC address on the virtual interfaces.

The first Linux Guest (call it A) has the NIC configured as follows:

NIC 2: MAC: 080027823BE6, Attachment: Internal Network 'intnet1', Cable connected: on, Trace: on (file: foobar.pcap
), Type: virtio, Reported speed: 0 Mbps, Boot priority: 0, Promisc Policy: allow-all, Bandwidth group: none

The second Linux Guest (call it B) has the NIC configured as follows:

NIC 2: MAC: 0800278B0F78, Attachment: Internal Network 'intnet1', Cable connected: on, Trace: on (
p), Type: virtio, Reported speed: 0 Mbps, Boot priority: 0, Promisc Policy: allow-all, Bandwidth group: none

In other words I'm using "virtio" and I've configured the promiscuous policy to "Allow All". (Allow VMs doesn't work either).

I set up IP addresses in this interface (it's called "eth1" in each of the Linux systems). As I said for reasons that I don't have to go into here the Linux system wants to set its own MAC on the interface. So for purposes of this discussion call it MACA on system A and MACB on system B. That's why I'm having to use "Allow All" as the promiscuous policy.

If I now ping from system A to system B here is what happens.

System A sends a Broadcast ARP to resolve the MAC address for B. This packet is received by system B and of course a UNICAST reply is sent back with the resolution for MAC B.

System B then sends a unicast ARP packet (source MACB dest MACA) asking for the resolution of systemA's MAC.

The pcap trace file I've put on System B's NIC (foobar2.pcap) shows all of these packets. But the pcap trace file on system A (foobar.pcap) only shows the original ARP broadcast packet from system A to system B. It does NOT show either of the Unicast replies. So of course they don't make it into the System A Libux system and hence the ping doesn't work.

This is the behavior I'd expect had I not set promiscuous mode on the virtual NICs inside VirtualBox. But I have set promiscuous mode and I cannot understand why it is not working.

Please could someone explain what is happening to my Unicast packets. What exactly is filtering them and why? How do I fix it?

I've spent ages googling for a similar problem but my searches have come up dry, hence this post.

Thanks,

Dave

[dgarrod]

In case it helps I've added two attachments. foobar.txt shows the ARP requests being transmitted from the system A NIC, fooba22.txt shows the traffic on the receiving system B NIC. As you can see there are no unicast packets from B --> A shown in the trace from the NIC on system A. The trace from the NIC on system B shows the broadcast packet (A -> B) and also the unicast packets (B ->). The question of course is what happened to the unicast packets on their way from B to A inside the guts of Virtualbox?

[polytope]

+1 for this.

I have the _exact_ same problem, but my network setup is substantially more convoluted. Nonetheless, I have just two interfaces which are in an internal network; the first responds to an ARP request but the second never sees the response in the packet captures.

[mpack]

But in my case my Linux Guests set the Hardware MAC address on the virtual interfaces.

I doubt that. Ethernet MAC addresses are supposed to be a globally unique fingerprint and are hard coded in the firmware of the NIC. NICs don't offer any feature to change the MAC, and if they did then it is not via a standard API.

VirtualBox already supports the features of the NIC you select in the VM.

p.s. Moved to Linux Guests since your Windows Host is completely irrelevant to the question asked.

[dgarrod]

For anybody that is interested take a look at the thread:

https://www.mail-archive.com/vbox-dev@v ... 08369.html

The question is to why this doesn't work at present is answered there. There's an acknowledgment that it is a "bug" or at the very least "missing functionality".

The issue as I understand it is that when the guest sets the MAC address it makes it to the virtual device in Virtualbox but it does not make it to the internal network switching layer.

By the way you can set the MAC on a NIC. The MAC that is programmed is indeed globally unique at manufacturing times. But many network products override it for a number of reasons.

Regards,

Dave

[mpack]

Ah, I see you are talking only about VirtIO, not NICs in general. That wasn't clear to me before. I have no idea with the VirtIO-net spec allows.