Isolated Internal Network and Snapshots: Why They Are Essential

A lab is only useful if it is safe. Two features turn a pile of virtual machines into a safe laboratory: network isolation, which ensures that whatever happens in the lab stays in the lab, and snapshots, which let you travel back in time. In this lesson you will configure both, and you will understand the choices that your hypervisor offers.

You have a Kali VM, and soon a second machine. The question now is how they connect to each other, to your host, and to the Internet. The answer decides whether your lab is a protected greenhouse or a hole in your home network.

The virtual network modes

Each virtual network card of a VM can be attached to the outside world in different ways. The names vary slightly between VirtualBox and VMware, but the concepts are the same:

Mode	VM can reach the Internet?	VMs reach each other?	Host can reach VM?	Typical use
NAT	Yes, through the host	No (each VM is alone)	No, unless port forwarding	Updates, downloads
NAT network	Yes	Yes, in a shared private network	No, unless port forwarding	A lab that needs updates
Bridged	Yes, as a device on your real network	Yes, and with your real devices	Yes	Rarely in a lab: exposes the VM to your home network
Host-only	No	Yes	Yes	Lab with host access to the VMs
Internal network	No	Yes, only those on the same named network	No	Fully isolated lab

The important point for a security lab is the bridged mode: the VM appears on your real network, like another device. A vulnerable machine in bridged mode is a vulnerable machine on your home or company network, reachable by other devices. Equally, a tool running in a bridged Kali could easily reach your real devices. Avoid it for vulnerable machines and offensive tools.

Designing the isolated lab network

The recommended design combines two adapters, so that each machine has the right connectivity at the right time:

• Adapter 1: NAT, enabled only when you need to download updates or packages. Disable (unplug the virtual cable) when you finish.
• Adapter 2: internal network named, for example, labnet. All your lab machines are attached to this network, and it is invisible from everything else, including your host.

On an internal network, there is no DHCP server: nobody hands out addresses. You have two options. The first is to assign static addresses to the machines in a private range of your choice, for instance 10.10.10.0/24: Kali at 10.10.10.10, the Linux target at 10.10.10.20. This is excellent practice because you must apply what you learned in chapter 1, and is reflected in your notebook. The second is to run a small DHCP service in one VM of the lab. For a first lab, the static approach is the clearest.

On a Debian-based system, you can check the interface names with ip addr show and set an address temporarily from the terminal:

sudo ip addr add 10.10.10.10/24 dev eth1
sudo ip link set eth1 up
ip addr show eth1

Replace eth1 with the real name of the second interface, which can differ on your system. This change disappears at reboot, which is fine for a first test. For a permanent setting, use the network configuration tool of your distribution (graphical or through the files that it documents). Then test the link between your two VMs with ping 10.10.10.20 from Kali. If it works, you have built your first private network, using the vocabulary of chapter 1: a /24, two hosts, no gateway because there is no need to leave the network.

A good test of isolation: from a lab machine, try to reach something outside, such as ping 192.168.1.1 (your home gateway, if that is your network range) with only the internal adapter enabled. It should fail. If it succeeds, an adapter is in the wrong mode and you must fix it before going further.

What isolation protects against

• Accidents: a scan or a test that you launch by mistake cannot leave the lab.
• Vulnerable machines on your real network: intentionally weak systems stay unreachable by others.
• Malware samples (if you study them in advanced courses) cannot reach your host or the Internet.
• Mistakes of identity: when everything in the network belongs to you, you can never target a third party by typing a wrong address.

That last point is more important than it seems. Many legal problems of beginners come not from bad intentions but from a typing mistake, for example a wrong address in a command. If your lab is isolated, such an error has no consequence.

Snapshots: a time machine for VMs

A snapshot records the complete state of a VM at a given moment: its disk, and optionally its memory. You can continue to work and, whenever you want, restore the snapshot to return the machine exactly to that state, as if nothing had happened. Snapshots are the best friend of anyone who tests software or techniques.

Use them systematically:

• Before an experiment: take a snapshot named clearly, such as "before-config-change" or "clean-install-updated".
• After a successful configuration: save it as a milestone you can come back to.
• After a failure: restore the snapshot rather than trying to undo the damage manually.

A snapshot is not a backup. It lives in the same storage as the VM: if the disk fails or the VM folder is deleted, the snapshots are lost with it. A long chain of snapshots also slows the VM and consumes disk space. Keep a few meaningful ones, delete the ones you no longer need, and export important machines as a file stored elsewhere. Also, remember that restoring a snapshot erases everything that happened afterwards in the VM, including your notes if you wrote them there: keep your notebook on the host.

Many professional security teams work exactly this way: a library of clean "golden images", cloned and reverted at will for each exercise.

Cloning

A related function is cloning: it creates a copy of a VM. A linked clone shares the disk of its original and saves space; a full clone is independent. Cloning is handy for building several similar machines from one prepared template. If you clone a machine, remember to give each copy its own name and its own network address, otherwise two machines would conflict.

Your turn: build and test your lab network

Create a second VM, a small Debian-based Linux server (as it will serve for chapter 4). Configure for both VMs a second network adapter in internal network mode, with the name labnet. Give Kali 10.10.10.10/24 and the server 10.10.10.20/24. Take a snapshot of each. Then ping one from the other. Next, delete a file of your choice inside the server, restore the snapshot, and verify that the file is back. Note everything in your lab notebook, and add a small diagram of the network.

See a solution

The diagram has a single segment, labnet (10.10.10.0/24), with the two VMs attached. The ping from 10.10.10.10 to 10.10.10.20 should answer. If it does not, check that both adapters use the exact same network name (the name is case-sensitive in some hypervisors), that the interfaces are up, that the addresses are in the same /24, and that no firewall inside a VM blocks ICMP. After restoring the snapshot, the deleted file is back, proving that the VM returned to its previous state. Also try disabling the NAT adapter and checking that no Internet access remains: this is the proof of isolation you want before you ever run security tools.