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:
- After your virtual machine just booted up, it uses original MAC address to request things on the Internet.
- VirtualBox's NAT engine will also needs your virtual machine's MAC address1 in order to pass things from the Internet back to it.
- 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.
- 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.
- You changed your virtual machine's MAC address to a newly made-up one, without changing its IP address.
- When you do Internet request from your virtual machine again, it uses new MAC address to request it.1
- VirtualBox's NAT engine receives your request (but only cares about your IP, not MAC) and forwards it to the Internet normally.
- When the Internet responds, VirtualBox's NAT engine needs your virtual machine's MAC address to pass this response back to your virtual machine.
- 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).
- VirtualBox's NAT engine sends Internet response to your virtual machine's old MAC address, rather than the new one.
- 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)
1 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.