Internet not working on my kali-linux VM

Question

I am setting up some virtual machines on Oracle VM using Kali-linux as operating system. When I create the first NAT network internet usually works but as soon as I do something like changing my MAC address the internet connection stops working, even though the machine says that the wired connection is connected.

If I want the connection to work I have to create a new NAT network each time but after a while it will stop working, and I believe this is associated with me changing my mac address which I do as follow:

ifconfig eth0 down
ifconfig eth0 hw ether 'new mac address'
ifconfig eth0 up

Does anyone know what might be going wrong during this process?

These are the current results from my ifconfig:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.2.4  netmask 255.255.255.0  broadcast 10.0.2.255
        inet6 fe80::a00:27ff:fe82:e693  prefixlen 64  scopeid 0x20<link>
        inet6 fd17:625c:f037:2:a00:27ff:fe82:e693  prefixlen 64  scopeid 0x0<global>
        inet6 fd17:625c:f037:2:8c24:fafd:c5e0:725c  prefixlen 64  scopeid 0x0<global>
        ether 08:00:27:82:e6:93  txqueuelen 1000  (Ethernet)
        RX packets 44  bytes 11250 (10.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 423  bytes 38119 (37.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 24  bytes 1356 (1.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 24  bytes 1356 (1.3 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Answer 1

What you observed here are phenomena happening when you pulled the rug out from under your TCP/IP stacks :D

Note that there are actually two phenomena in the play here...

1. The Pitfall of Missing Default Gateway

This one is simple:

Running ifconfig eth0 down deletes your default gateway configuration from your virtual machine's routing table; because the network associated to that gateway is removed.

Running ifconfig eth0 up WILL NOT restore your default gateway; it will retain only old IP address and subnet mask. If you try to run route -n, you won't see any line with G under "Flags" column.

Once this happens, any programs in your virtual machine that tries to access the Internet will get either "Host not found", or "Network is unreachable" error.

You will have to run route add default gw GATEWAYIP manually, to restore your default gateway.

• Don't forget to substitute GATEWAYIP with your actual default gateway address. Check your /etc/network/interfaces or run route -n command (and look for a "Gateway" column of the line with G under "Flags" column) before doing this dirty deeds; but it is probably 10.0.2.2 under VirtualBox anyway.

But even after restoring default gateway, you would find that your virtual machine still can't connect to the Internet; or more precisely, Internet can't reply back to it. That is because...

2. The Effect of Lingering ARP Cache

You know that the TCP/IP over Ethernet uses ARP to find MAC address to match with IP in order to really communicate, right?

This is a timeline of what's happening inside your VirtualBox instance, as far as I figured:

1. After your virtual machine just booted up, it uses original MAC address to request things on the Internet.
2. VirtualBox's NAT engine will also needs your virtual machine's MAC address¹ in order to pass things from the Internet back to it.
3. VirtualBox's NAT engine initially doesn't know which MAC address your virtual machine have; so it issues ARP request, and your machine answered it with its original MAC address.
4. VirtualBox's NAT engine stores your virtual machine's MAC address (and associating IP address) in its ARP cache; which is a very normal thing to do.
5. You changed your virtual machine's MAC address to a newly made-up one, without changing its IP address.
6. When you do Internet request from your virtual machine again, it uses new MAC address to request it.¹
7. VirtualBox's NAT engine receives your request (but only cares about your IP, not MAC) and forwards it to the Internet normally.
8. When the Internet responds, VirtualBox's NAT engine needs your virtual machine's MAC address to pass this response back to your virtual machine.
9. VirtualBox's NAT engine looks up your virtual machine's IP address in its own ARP cache, and found a non-expired record of MAC address, so it doesn't issue ARP request again. (Though, unknown to VirtualBox- that the MAC address found was the old, outdated one).
10. VirtualBox's NAT engine sends Internet response to your virtual machine's old MAC address, rather than the new one.
11. Your virtual machine (which is using new MAC address) does not get the response, and timed out; thus "Internet not working on my kali-linux VM".

Even after the default gateway configuration got fixed, Internet access in your virtual machine will continue to be broken until said ARP cache entry expires, or you changed your virtual machine's IP address.

Bottom Line

I don't know how long VirtualBox's NAT engine caches ARP response internally; so I would suggest a workaround by changing IP address of your virtual machine as soon as you changed its MAC address, to prevent second effect. Also, after you changed IP address and brought the interface up, make sure you re-add the default gateway too to prevent the first pitfall. (Use route -n | grep UG to verify)

---

¹ One might think that VirtualBox's NAT engine should have learned of virtual machine's MAC address from each request packet itself, this is not the way things are done; because it would allow so much of casual IP/MAC address spoofing. So, only MAC address solicited by explicit ARP requests are used/cached for routing; not ones learned from random data packets.