No network connection after changing MAC address within Debian guest

[anonymous]

I use the latest VirtualBox version under Windows 10 Home x64. I created a VM with Debian 8.7 x64. Everything works fine, except one thing:

When I change the MAC address within the Debian system, I do not have a working network connection to or from the VM anymore. No LAN, no Internet, no IPv4, no IPv6. But "ifconfig", "ip addr show" and "ip route show" do not show any hints what's wrong.

I already googled for many hours and tried many things, it does not work. What's working is the changing of the MAC address.

I know that you now have the question why I want to change the MAC address from within Debian. Of course I'm aware of the fact that I can change the MAC address in the VM settings. The background is that I want to test the network settings of my dedicated root server which hosts my websites (which has nothing to do with the VM or my local PC). My provider forces me to set a specific MAC address for every IP (I have several IPs and I want to use several). And to prevent that I cannot reach my remote server anymore I test the settings in the VM first.

Now back to my problem. I guess it has do to something with VirtualBox and not Debian itself. I changed the MAC address in several ways (not simultaneously, of course), via "hwaddress" or "hwaddress ether" in the "/etc/network/interfaces", via "/etc/systemd/network/00-default.link" or via "ip link set dev interface address XX:XX:XX:XX:XX:XX". The MAC address is set then, but the connection is gone every time.

I often read of a new network interface which is generated in the "/etc/udev/rules.d/70-persistent-net.rules", but that's not the problem here. In this file only one interface (eth0) is defined, even if I change the MAC address in the VM settings.

Attached a screenshot of my network settings of the VM.

What can I do? Or is this impossible within a VirtualBox VM?

[Martin]

VBox doesn't really support changing the MAC address from inside a guest VM.
The "official" working method is to change the address in the VM setting (your screenshot) when the guest is shutdown completely.

[anonymous]

Thanks for your quick reply, although it's a frustrating information...

But what's the reason for the loss of the connection? I mean, changing the MAC address IS possible from within the Debian guest.

Is this a problem of VM softwares in general or just with VirtualBox?

[Perryg]

The guests MAC information is generated from the physical hardware and in this case that would be the VirtualBox network adapter. You simply need to change the address to what ever you want in the guest settings of VirtualBox while the guest is shut down ( not saved ). If the guest does not behave properly after that you just need to delete the "/etc/udev/rules.d/70-persistent-net.rules" and reboot so the guest can generate it again, or edit it if you feel like it ( still requires a reboot ).

[anonymous]

Changing the MAC address via the VM settings works fine, but that's not the point here. I want to (have to) test a MAC address change via the Debian system (for example via the "/etc/network/interfaces").

[Perryg]

Without knowing why exactly you need this, I can tell you that VirtualBox uses the hardware on the host and provides an address for the guest just like on metal. I know of no other way or any other hardware or virtualizer that works differently. You can try MAC address spoofing but these days most sources can detect this and will block it.

Ask yourself this. On the host can you change the address to anything you want and still get access to the LAN/Internet?

[anonymous]

Did you read the first post in this thread? I think I described in detail why I need this. And that I already know the file "/etc/udev/rules.d/70-persistent-net.rules".

[Perryg]

Yes I read it all, but somehow I can't convey to you that what you want does not exist, real or virtual. Perhaps I should leave it to someone else that might be better at communicating than I am.

[anonymous]

but somehow I can't convey to you that what you want does not exist

You said these things, which would not be necessary when reading post #1:

If the guest does not behave properly after that you just need to delete the "/etc/udev/rules.d/70-persistent-net.rules"

Without knowing why exactly you need this

If it's just not possible in a VirtualBox VM, then please just say this (although Martin already said it). The only missing information, which I requested, is why the network loss occurs. I just want to understand the technical background. Changing the MAC address on a physical Linux machine is possible and does not lead to this problem.

[Perryg]

Changing the MAC address on a physical Linux machine is possible and does not lead to this problem.

This statement can not be true. MAC addresses are hard coded in the network adapter. If you change the address to something other than the real adapter address it will not know how to get to the LAN.
ARP requests ( google it to see what this is ) are sent to the MAC address of the device and that is why you loose the connection when you simply change the address in the guest.

Anyway we could do this all days and I can sense you are getting more and more frustrated as time goes on. I understand and wish you the best, but I have other things to do and do not want to burden you further.

[Martin]

Perry, it seems we are talking here about 'locally administered addresses'.
But as far as I know Vbox doesn't support this.
viewtopic.php?f=6&t=82210#p387875
viewtopic.php?f=3&t=68426

[anonymous]

This statement can not be true

it seems we are talking here about 'locally administered addresses'

Well, I don't know how to name the MAC address change which I mean, but I know that my provider forces me to do so. And I guess they would know if it's not possible at all. It's a provider with about 70,000 customers.

But now I know that it's impossible within a VirtualBox guest and I do not have to try or research more. Thanks to you both.

EDIT: Oh, link #2 contains the solution!

Code: Select all

ifconfig eth0 promisc

Thanks Martin!