Build an Isolated VirtualBox Cyber Range

Build a two-node VirtualBox cyber range and prove network isolation.

Introduction

30 Second Summary

Testing network behavior on your everyday computer can put personal files or nearby devices within reach of a mistake. A dedicated local lab gives every experiment a clear boundary.

In this project, you will build a two-node cyber range in Oracle VirtualBox using Kali Linux beside Alpine Linux. You will use a named Internal Network with static IPv4 addressing to permit peer traffic without an external default route.

What You'll Build

Your finished demonstration pairs a successful ping from KALI-OPS to RANGE-PEER across range-lan with a routing table that has no IPv4 default route.

By the end of this project, you'll have:

  • Run both lab guests at the same time on an 8 GB Windows host while each remains responsive.
  • Prove the traffic boundary through a successful peer ping beside a routing table with no IPv4 default route.
  • Present the evidence using a local pack that connects the range architecture to its isolation results.
  • Secret Mission: Move RANGE-PEER onto range-quarantine to prove communication stops before returning it safely to range-lan.

Are there any prerequisites?

You'll need an x64 Windows PC with 8 GB of RAM, at least 30 GB of free storage, and hardware virtualization enabled. This project assumes Oracle VirtualBox plus 7-Zip are installed alongside either an existing Kali Linux VM or the official Kali VirtualBox archive.

Before We Start

A cyber range needs a clear boundary before any machines or networks change. This checkpoint connects every later action to a safe learning objective that you control.

Verify the Lab and Add a Lightweight Peer

Your authorized scope statement keeps every test tied to systems you own. The next priority is a known-good local lab foundation.

Oracle VirtualBox provides the hypervisor that runs the range. You will verify it through Windows PowerShell. You will also confirm that 7-Zip can prepare your existing Kali Linux image before you add an Alpine Linux peer.

In this step, get ready to:
  • Verify the Windows tools that support your local cyber range.
  • Confirm that your existing Kali Linux VM is registered in VirtualBox.
  • Verify the Alpine ISO before using it to boot a lightweight peer.
Verify the lab tools and Kali VM

The hypervisor controls every virtual machine in the range. Checking its version first prevents the rest of the project from depending on an unknown installation.

  • Press the Windows key to open the search bar.
  • Type Windows PowerShell into the search bar.
  • Press Enter to open Windows PowerShell.
  • Check the installed VirtualBox version by running this command:
& 'C:\Program Files\Oracle\VirtualBox\VBoxManage.exe' --version

What does this command check?

The command runs VirtualBox through its default Windows installation path. The returned version confirms that Windows PowerShell can reach the management tool used throughout this project.

  • Press the Windows key to search for 7-Zip.
  • Type 7-Zip into the search bar.
  • Open the installed 7-Zip application from the search results.
  • Use the application's version information to check the installed release.

✔️ Both tools are current

Your VirtualBox output reports 7.2.16. Your 7-Zip installation reports 26.03. Your local tools are ready for the VM files used in this range.

ⓧ I see an older tool version

An older installation can produce different screens or command behavior. Align both tools with the project versions before continuing.

These installers update software on your Windows PC. They create no cloud resources or service charges.

  • Download Oracle VirtualBox 7.2.16 from the official VirtualBox download directory.
  • Run VirtualBox-7.2.16-174877-Win.exe to update VirtualBox.
  • Download 7-Zip 26.03 for Windows x64 from the official 7-Zip download page.
  • Run the downloaded 7-Zip installer.
  • Approve administrator access only for installers downloaded from those official pages.
  • Repeat the VirtualBox version command from above.
  • Recheck the 7-Zip version information.

ⓧ A tool is missing

A missing result means the required application needs to be installed before its files or commands can be used.

These installations remain on your local Windows PC. They do not create paid resources.

  • Download Oracle VirtualBox 7.2.16 from the official VirtualBox download directory if VirtualBox is missing.
  • Run VirtualBox-7.2.16-174877-Win.exe if you downloaded it.
  • Download 7-Zip 26.03 for Windows x64 from the official 7-Zip download page if 7-Zip is missing.
  • Run the downloaded 7-Zip installer if you downloaded it.
  • Approve administrator access only for installers downloaded from those official pages.
  • Repeat the VirtualBox version command from above.
  • Recheck the 7-Zip version information.

Still unable to verify the tools?

Confirm that VirtualBox uses its default installation folder. Reinstall it from the official directory if the executable is missing from that location.

Check that you selected the Windows x64 release of 7-Zip. Help me diagnose why VirtualBox or 7-Zip is missing on my x64 Windows PC. Share only non-sensitive installation details with the NextWork community if the issue depends on your machine.

  • Check which virtual machines VirtualBox already knows about by running this command:
& 'C:\Program Files\Oracle\VirtualBox\VBoxManage.exe' list vms

What does the VM list prove?

VirtualBox stores a registration for every VM it can manage. Seeing your Kali VM here confirms that later commands can target it without importing another copy.

✔️ My Kali VM is listed

Your existing Kali VM is registered. Keep its current registered name for now.

ⓧ I have the Kali archive

The downloaded archive must pass its official hash check before you extract it. A matching hash proves that the file has the same contents published by Kali.

  • Replace <path> with the folder containing your Kali archive.
  • Calculate the archive's SHA-256 hash by running the edited command:
Get-FileHash -Path '<path>\kali-linux-2026.2-virtualbox-amd64.7z' -Algorithm SHA256

What does the hash prove?

A cryptographic hash acts as a fingerprint for the archive. Character-for-character equality confirms that the downloaded file matches the official Kali release.

  • Compare the displayed hash with 41ed7ec51cdd3a5ca663ec09492261ba81acb26625fdda85ce7acb16909f3cee.
  • Return to 7-Zip from the version check.
  • Locate kali-linux-2026.2-virtualbox-amd64.7z in 7-Zip.
  • Extract the verified archive into its own folder.
  • Open the extracted folder in File Explorer.
  • Double-click the included .vbox file to register the VM.
  • Repeat the VirtualBox VM listing command from above.

ⓧ I need the Kali archive

Use the official prebuilt Kali VM so the archive contains both the virtual disk and its VirtualBox metadata.

  • Download kali-linux-2026.2-virtualbox-amd64.7z from the official Kali 2026.2 archive directory.
  • Replace <path> with the folder containing the downloaded archive.
  • Calculate the archive's SHA-256 hash by running the edited command:
Get-FileHash -Path '<path>\kali-linux-2026.2-virtualbox-amd64.7z' -Algorithm SHA256

Why verify before extraction?

The checksum verifies the downloaded archive before 7-Zip expands its contents. This keeps a damaged or altered image out of your lab.

  • Compare the displayed hash with 41ed7ec51cdd3a5ca663ec09492261ba81acb26625fdda85ce7acb16909f3cee.
  • Return to 7-Zip from the version check.
  • Locate the verified archive in 7-Zip.
  • Extract the archive into its own folder.
  • Open the extracted folder in File Explorer.
  • Double-click the included .vbox file to register the VM.
  • Repeat the VirtualBox VM listing command from above.

Kali still missing from the VM list?

Confirm that you opened the extracted .vbox file. Opening the .vdi disk alone does not register the supplied VM configuration.

Repeat the VM listing command after VirtualBox finishes registering the file. Help me register an extracted Kali VirtualBox VM from its .vbox file. Share the non-sensitive VM list with the NextWork community if registration still fails.

Download and verify the Alpine ISO

The Alpine Virtual image is optimized for virtual systems. Its small live environment gives your range a second endpoint without consuming the resources required by another desktop VM.

  • Visit the official Alpine x86_64 release directory.
  • Download alpine-virt-3.24.1-x86_64.iso.
  • Download the adjacent alpine-virt-3.24.1-x86_64.iso.sha256 file.
  • Keep both downloaded files in the same folder.
  • Replace <path> with the folder containing the Alpine ISO.
  • Calculate the ISO's SHA-256 hash by running the edited command:
Get-FileHash -Path '<path>\alpine-virt-3.24.1-x86_64.iso' -Algorithm SHA256

Why use the adjacent checksum file?

The adjacent checksum file comes from the same official release directory as the ISO. Comparing against that file avoids trusting a hash copied from an unrelated page.

  • Open alpine-virt-3.24.1-x86_64.iso.sha256 in a text editor.
  • Compare the PowerShell digest with the checksum in that file.
  • Continue only when every character matches.

Checksum does not match?

Download both files again from the official Alpine directory. Confirm that the checksum filename matches the ISO filename before comparing them.

A partial download also produces a different digest. Help me troubleshoot an Alpine ISO checksum mismatch in Windows PowerShell.

Create and boot RANGE-PEER

The Alpine ISO loads a complete system into RAM. This makes the peer disposable during the project because changes inside the live session disappear after a power cycle.

Why use Alpine for the peer?

The peer only needs to expose an Ethernet interface and answer network tests. Alpine provides that capability with a small memory footprint, which leaves enough host capacity for Kali.

  • Press the Windows key to open the search bar.
  • Type Oracle VirtualBox into the search bar.
  • Press Enter to open VirtualBox Manager.
  • Start the create-VM flow from VirtualBox Manager.
  • Enter RANGE-PEER as the virtual machine name.
  • Select alpine-virt-3.24.1-x86_64.iso under ISO Image.
  • Deselect Install OS Using Unattended Installation.
  • Set Base Memory to 512 MB.

Keep the peer lightweight

A small peer keeps both VMs usable on an 8 GB Windows host. The live Alpine system needs only enough resources to boot and participate in later network tests.

  • Set Processors to 1.
  • Set Disk Size to 1 GB.
  • Choose dynamic allocation for the virtual disk.
  • Complete the wizard to create RANGE-PEER.
  • Select RANGE-PEER in VirtualBox Manager.
  • Click Start.
  • Wait for the Alpine login prompt.
  • Type root at the login prompt.
  • Press Enter to log in.
  • Leave the password empty if Alpine requests one.
  • Press Enter to submit the empty password.
  • Keep the VM running at its root shell prompt.
  • Do not run setup-alpine.

You should reach an Alpine root shell without entering a password. The operating system is now running directly from the verified ISO.

Alpine does not reach the login prompt?

Check that the verified Alpine ISO remains attached to RANGE-PEER. Confirm that unattended installation is disabled.

Recheck the VM's 512 MB memory allocation if it closes during boot. Help me diagnose why RANGE-PEER does not boot the Alpine Virtual ISO.

Before you run the final check, which VM names do you expect VirtualBox to report?

  • Confirm that VirtualBox registered your Kali VM and RANGE-PEER by running this command:
& 'C:\Program Files\Oracle\VirtualBox\VBoxManage.exe' list vms

What does this final check prove?

The command reads VirtualBox's registered VM inventory. It confirms that the hypervisor can manage both endpoints before you change their resource or network settings.

You should see your Kali VM and RANGE-PEER in the output. Switch back to the peer to confirm that its Alpine root shell remains responsive.

RANGE-PEER missing from the list?

Return to VirtualBox Manager to confirm that the creation wizard completed. Check for the exact VM name RANGE-PEER.

Keep the Alpine VM window open after it reaches the root shell. Help me diagnose why RANGE-PEER boots but does not appear in VBoxManage list vms.

That is the local foundation in place. Your verified Kali VM now has a lightweight Alpine peer ready for the first two-node boot test.

Boot the Two-Node Lab

Your Oracle VirtualBox environment already has a registered Kali Linux VM. A lightweight Alpine Linux peer is ready beside it.

The next goal is to keep both consoles responsive on your 8 GB Windows host. NAT gives you a default-network baseline. The explicit isolated boundary is still missing.

In this step, get ready to:
  • Rename the Kali VM to KALI-OPS with resource limits suited to your Windows host.
  • Place adapter 1 on both virtual machines in NAT mode.
  • Record the default IPv4 configuration while both VM consoles remain responsive.
Rename and Right-Size Kali

Renaming the existing guest creates a stable identity for every later network command. Resource limits preserve enough host capacity for the peer.

Windows PowerShell applies both settings through the VirtualBox command-line interface. The Kali VM must be powered off before its configuration changes.

  • Shut down the Kali VM through its desktop power menu.
  • Switch back to Windows PowerShell from earlier.
  • List the registered virtual machines by running this command:
& 'C:\Program Files\Oracle\VirtualBox\VBoxManage.exe' list vms

What Does This Command Show?

Each line shows a registered VM name followed by its unique identifier. The quoted Kali name is the value that the next command must target.

  • Locate the quoted name of your registered Kali VM.
  • Record the name without its surrounding quotation marks here: current-Kali-name.
  • Rename the VM to KALI-OPS with 2048 MB of memory plus 2 CPUs by running this command:
& 'C:\Program Files\Oracle\VirtualBox\VBoxManage.exe' modifyvm "[[CURRENT_KALI_NAME="current-Kali-name"]]" --name "KALI-OPS" --memory 2048 --cpus 2

What Does This Command Change?

  • The --name setting gives the operations VM its permanent lab identity.
  • The --memory setting assigns 2048 MB of host memory.
  • The --cpus setting assigns 2 virtual processors.
  • Wait for Windows PowerShell to return to its prompt.

A clean return to the prompt confirms that VirtualBox accepted the configuration change.

Kali Configuration Not Applying?

Confirm that the Kali VM is fully powered off. Check that the registered name matches the output from the VM list character for character.

Ask for help with diagnosing the VirtualBox VM modification.

Set Both Adapters to NAT

Both guests need the same known starting mode before you introduce isolation. Adapter 1 provides that baseline through VirtualBox NAT.

  • In VirtualBox Manager, select RANGE-PEER from the machine list.
  • Use the power controls in its console window to shut it down.
  • Return to Windows PowerShell.
  • Set adapter 1 on both VMs to NAT by running these commands:
& 'C:\Program Files\Oracle\VirtualBox\VBoxManage.exe' modifyvm "KALI-OPS" --nic1 nat
& 'C:\Program Files\Oracle\VirtualBox\VBoxManage.exe' modifyvm "RANGE-PEER" --nic1 nat

What Does NAT Provide?

The --nic1 nat setting attaches adapter 1 to VirtualBox NAT. Applying the same starting mode makes the later isolation change easy to compare.

  • Return to VirtualBox Manager.
  • Select KALI-OPS in the machine list.
  • Click Start in the toolbar.
  • Sign in to Kali with the credentials for your VM.
  • Select RANGE-PEER in the machine list.
  • Click Start in the toolbar.
  • Enter root at the Alpine login prompt.

Alpine logs you in without asking for a password. Both guest consoles are now running together.

One of the VMs Not Starting?

Confirm that no other local virtual machines are consuming the host's memory. Check that KALI-OPS has 2048 MB while RANGE-PEER has 512 MB.

Ask for help with starting both VirtualBox guests within the host limits.

Capture the Default-Network Baseline

A baseline records what the guests can see before their network boundary changes. You will compare these outputs with the isolated state later.

  • Open a terminal from Kali's desktop application menu.
  • Predict whether Kali will show an IPv4 address plus a route beyond its local interface.
  • Inspect Kali's IPv4 addresses plus routes by running these commands:
ip -4 address show
ip -4 route show

What Do These Results Describe?

The address output shows the IPv4 configuration attached to each Kali interface. The route output shows where Kali currently sends traffic beyond directly connected destinations.

  • Keep the Kali terminal visible with both command results.
  • Switch to the RANGE-PEER console.
  • Inspect Alpine's IPv4 addresses by running this command:
ip -4 address show

What Does the Peer Output Add?

This output records the peer's current IPv4 interface state under NAT. Together with the Kali results, it forms the default-network baseline for both nodes.

You can now see IPv4 interface details in both guests. Kali also shows its current routing table.

  • Return to VirtualBox Manager.
  • Confirm that KALI-OPS shows a running state.
  • Confirm that RANGE-PEER shows a running state.
  • Arrange the Kali terminal beside the Alpine console on your Windows desktop.

Missing IPv4 Output?

Check that adapter 1 is enabled on the affected VM. Confirm that its attachment mode is NAT before restarting that guest.

Ask for help with diagnosing missing guest IPv4 information.

That is your first visible win. Both nodes now run together within the host limits. Next, you will replace NAT with the named internal boundary that turns them into an isolated range.

Move Both Machines to the Internal Network

The NAT baseline proved that Kali Linux and Alpine Linux can run at the same time on your host. However, NAT still gives each guest an outbound path instead of a shared lab boundary.

A VirtualBox Internal Network creates a named switch that only selected VMs can use. You will move both guests onto that switch.

The first boot exposes what the previous network supplied automatically. That visible gap gives you the evidence needed for the next configuration step.

In this step, get ready to:
  • Attach adapter 1 on both VMs to the named internal network range-lan.
  • Confirm both virtual adapters share the same hypervisor segment.
  • Restart both guests and inspect their IPv4 state.
Attach both adapters to range-lan

Both guests are still running from your NAT baseline. Powering them off gives VirtualBox a clean point to replace adapter 1.

  • Shut down KALI-OPS from the Kali desktop system menu.

VirtualBox Manager now shows that KALI-OPS is no longer running.

  • Return to the RANGE-PEER Alpine root prompt.
  • Power off RANGE-PEER cleanly by running this command:
poweroff

What does this command do?

The poweroff command shuts down the live Alpine guest cleanly. Its non-persistent session ends when the VM powers off.

VirtualBox Manager now shows that RANGE-PEER is no longer running.

  • Return to Windows PowerShell from the earlier checks.
  • Attach adapter 1 on both VMs to range-lan by running these commands:
& 'C:\Program Files\Oracle\VirtualBox\VBoxManage.exe' modifyvm "KALI-OPS" --nic1 intnet --intnet1 "range-lan"
& 'C:\Program Files\Oracle\VirtualBox\VBoxManage.exe' modifyvm "RANGE-PEER" --nic1 intnet --intnet1 "range-lan"

What do these commands change?

  • The --nic1 intnet setting changes adapter 1 from NAT to Internal Networking.
  • The --intnet1 "range-lan" setting connects adapter 1 to the named virtual segment.
  • Using the same network name places both virtual adapters on one isolated switch.

Commands will not apply?

  • Confirm both VM consoles have completely closed before retrying the commands.
  • Check that the VM names remain KALI-OPS and RANGE-PEER.
  • Confirm the VirtualBox executable still exists at C:\Program Files\Oracle\VirtualBox\VBoxManage.exe.

Help me diagnose a VirtualBox adapter configuration failure.

Confirm the shared internal network

Matching network names define membership in an Internal Network. Inspecting both VM configurations proves that the hypervisor placed them on the same segment.

  • Inspect both VM configurations from Windows PowerShell by running these commands:
& 'C:\Program Files\Oracle\VirtualBox\VBoxManage.exe' showvminfo "KALI-OPS"
& 'C:\Program Files\Oracle\VirtualBox\VBoxManage.exe' showvminfo "RANGE-PEER"

What does this check prove?

Each showvminfo result exposes the VM's configured virtual hardware. The adapter 1 details prove whether both guests use the intended attachment mode and network name.

  • Find adapter 1 in the KALI-OPS output.
  • Confirm its attachment mode is Internal Network.
  • Confirm its network name is range-lan.
  • Find adapter 1 in the RANGE-PEER output.
  • Confirm its attachment mode is Internal Network.
  • Confirm its network name is range-lan.

Good progress. Both virtual adapters now meet on the same named switch without changing either VM's resource limits.

Still seeing NAT?

  • Confirm you inspected adapter 1 rather than another virtual adapter.
  • Run the matching modifyvm command again while the affected VM is powered off.
  • Repeat the showvminfo check for the affected VM.

Help me correct a VM that still reports NAT.

Inspect the isolated guest state

The hypervisor configuration proves that the shared segment exists. Guest inspection reveals the runtime effect of leaving NAT behind.

  • Return to VirtualBox Manager.
  • Select KALI-OPS in the VM list.
  • Click Start.
  • Select RANGE-PEER in the VM list.
  • Click Start.

You'll see the Kali desktop become responsive again. The Alpine console returns to its login prompt.

  • Enter root at the Alpine login prompt.
  • Press Enter at the password prompt without typing a password.

Before you inspect the guests, do you think their NAT-provided IPv4 settings survive the move to a new virtual segment?

  • Inspect Kali's IPv4 address and route by running these commands in its terminal:
ip -4 address show
ip -4 route show

What do the Kali checks reveal?

  • The ip -4 address show command lists the IPv4 addresses currently assigned to Kali's interfaces.
  • The ip -4 route show command lists the IPv4 paths Kali can currently use.
  • Inspect Alpine's IPv4 addresses by running this command at its root prompt:
ip -4 address show

What does the Alpine check reveal?

The command lists every IPv4 address currently assigned inside RANGE-PEER. This gives you the peer-side view of the new segment.

Kali's routing output contains no IPv4 default route. Neither guest has a 10.10.10.x lab address.

That is the boundary doing its job. Both guests share range-lan without a configured path to the host or outside network.

Why did the addresses disappear?

The Internal Network has no configured DHCP service. The guests therefore receive no automatic IPv4 configuration after leaving NAT.

This missing configuration is the intended shortfall. You have isolated the range before granting any deliberate peer connectivity.

Your two-node range now has a hypervisor-enforced boundary, but its guests have no lab addresses. Next, you'll assign intentional IPv4 addresses without restoring an external gateway.

Assign Static IPv4 Addresses

Your two guests already share range-lan through a VirtualBox Internal Network. That boundary keeps host connectivity outside the lab.

The network has no DHCP service, so neither guest received an IPv4 lab address. This step gives each endpoint a deliberate static address while the design continues to omit a gateway.

In this step, get ready to:
  • Configure KALI-OPS with the static address 10.10.10.10/24.
  • Assign the temporary address 10.10.10.20/24 to RANGE-PEER.
  • Prove that the guests can exchange ICMP traffic without an IPv4 default route.
Assign Kali's static address

Kali stores interface settings in a NetworkManager connection profile. You need the exact Ethernet profile name before you can change its addressing policy.

  • Return to the KALI-OPS terminal.
  • List the available NetworkManager profiles by running this command:
nmcli connection show

What Does This Command Show?

The command lists every NetworkManager connection profile known to Kali. The Ethernet profile is the one attached to the virtual network adapter.

  • Identify the Ethernet connection profile in the command output.
  • Record its name as your Ethernet profile name.

The next commands replace automatic addressing with a manual address. Kali may request your account password when sudo changes the profile.

  • Replace <profile-name> in both commands with your Ethernet profile name.
  • Apply the static profile configuration by running these commands:
  • Enter your Kali account password if a password prompt appears.
sudo nmcli connection modify "<profile-name>" ipv4.method manual ipv4.addresses "10.10.10.10/24" ipv4.gateway "" ipv4.dns ""
sudo nmcli connection up "<profile-name>"

How Does This Preserve Isolation?

  • The ipv4.method manual setting gives the profile a fixed addressing policy.
  • The address 10.10.10.10/24 identifies Kali on the lab network.
  • The empty ipv4.gateway "" value leaves the profile without an external gateway.
  • The empty ipv4.dns "" value leaves the profile without a DNS server.
  • The connection up command activates the updated profile.
  • Confirm Kali's address and routing table by running these commands:
ip -4 address show
ip -4 route show

What Should Kali Show?

You should see 10.10.10.10/24 on the Ethernet interface. The routing table should omit an IPv4 default route.

Kali Address Missing?

  • Check that the profile name matches the Ethernet row from nmcli connection show exactly.
  • Check that 10.10.10.10/24 appears in the profile modification command.
  • Activate the same profile name that you modified.

Ask for help with a missing Kali static address.

Assign Alpine's temporary address

Alpine is running as a live system from the ISO. Its network address lives in memory and must be reapplied after a power cycle.

  • Switch back to the RANGE-PEER console.
  • List the peer's network interfaces by running this command:
ip link show

Which Interface Do You Need?

The output includes a loopback interface and the Ethernet interface connected to range-lan. The Ethernet interface is the one that needs the peer address.

  • Identify the Ethernet interface that is not the loopback interface.
  • Record its name as your Ethernet interface name.
  • Replace <interface-name> in both commands with your Ethernet interface name.
  • Apply the peer interface configuration by running these commands:
ip link set dev <interface-name> up
ip address add 10.10.10.20/24 dev <interface-name>

What Do These Commands Do?

  • The ip link set dev <interface-name> up command makes the identified Ethernet interface active.
  • The ip address add 10.10.10.20/24 dev <interface-name> command assigns the peer's temporary lab address.
  • Confirm the peer's address and routing table by running these commands:
ip -4 address show
ip -4 route show

What Should the Peer Show?

You should see 10.10.10.20/24 on the identified Ethernet interface. The routing table should have no IPv4 default route.

Peer Address Missing?

  • Check that you replaced every <interface-name> placeholder with the interface name shown by ip link show.
  • Check that the interface is up before assigning 10.10.10.20/24.
  • Skip the address command if the interface already shows 10.10.10.20/24.

Ask for help with the Alpine interface configuration.

Test peer communication and routing

Both guests now have addresses in the same lab network. An ICMP echo test reveals whether traffic can cross range-lan between them.

Before you run the test, do you expect Kali to receive replies from the peer now that both addresses use the same network?

  • Return to the KALI-OPS terminal.
  • Test communication with RANGE-PEER by running this command:
ping -c 3 -4 10.10.10.20

What Proves Communication Works?

You should see three echo replies from 10.10.10.20. Those replies prove that KALI-OPS can reach RANGE-PEER across range-lan.

That is the key result. Your guests can exchange traffic inside the isolated network while both routing tables omit an IPv4 default route.

No Echo Replies?

  • Check that Kali still shows 10.10.10.10/24.
  • Check that the peer still shows 10.10.10.20/24.
  • Confirm that both VirtualBox adapters remain attached to range-lan.

Ask for help with a failed peer ping.

Peer communication now works across range-lan. Next up, you will package the address plan and isolation checks into an evidence set.

Prove Isolation and Package Evidence

Your two guests now exchange ICMP traffic across range-lan. The three replies prove permitted peer communication.

A working ping alone cannot support a credible isolation claim. You also need a routing table showing that no unintended IPv4 default route exists.

Guest output proves the network state inside each VM. VirtualBox configuration proves the boundary outside them.

Your evidence pack connects those facts to your authorized learning scope. This gives you a complete record of what the range permits.

In this step, get ready to:
  • Capture final guest evidence for addressing, routing, and peer communication.
  • Confirm that both VM adapters share the same isolated network.
  • Package the architecture, scope, IP plan, screenshots, and test notes.
Capture the final guest evidence

The final guest checks establish the permitted path between the two systems. They also show the missing route that keeps the range isolated.

Before you run these checks, consider whether Kali can still reach its peer without an IPv4 default route.

  • Return to the terminal in KALI-OPS from earlier.
  • Collect Kali's final network evidence by running these commands:
ip -4 address show
ip -4 route show
ping -c 3 -4 10.10.10.20

What does this evidence prove?

  • The address output ties KALI-OPS to 10.10.10.10/24.
  • The route output should show the connected 10.10.10.0/24 route. It should contain no IPv4 default route.
  • The ping output should contain three echo replies from RANGE-PEER.

You should see Kali retain its static address and connected subnet. The successful ping should still report three replies from 10.10.10.20.

  • Keep the Kali terminal positioned so each result remains available in its scrollback.
  • Return to the root prompt in RANGE-PEER from earlier.
  • Collect the peer's final address evidence by running this command:
ip -4 address show

What does the peer output prove?

The peer output should show the temporary 10.10.10.20/24 address on the active Ethernet interface. This places both guests in the same IPv4 subnet.

You should see 10.10.10.20/24 attached to the active interface. Keep this output visible in the terminal scrollback.

Missing an address or ping reply?

Confirm that both guests are still running. Check that both addresses use the 10.10.10.0/24 subnet.

A restarted Alpine live session loses its temporary address. Reapply the peer address using the interface name you identified in the previous step.

Help me diagnose missing guest network evidence.

Confirm the hypervisor boundary

Guest output shows what each operating system can reach. The hypervisor configuration shows why that reachability stops at the lab boundary.

Both adapters must use the same named Internal Network. The shared name forms the virtual segment that carries permitted peer traffic.

  • Switch back to Windows PowerShell from earlier.
  • Inspect the registered network configuration for both VMs by running these commands:
VBoxManage showvminfo "KALI-OPS"
VBoxManage showvminfo "RANGE-PEER"

What does the VM configuration prove?

Each VM report should identify adapter 1 as attached to range-lan in Internal Networking mode. Matching network names prove that both guests share one hypervisor-controlled segment.

Internal Networking excludes host applications and the outside world. This configuration supports the isolation claim shown by the guest routing evidence.

You should find range-lan in the adapter 1 details for both KALI-OPS and RANGE-PEER.

  • Keep both VM reports available in the PowerShell scrollback.

Cannot run the VM inspection commands?

Use the verified VirtualBox executable at C:\Program Files\Oracle\VirtualBox\VBoxManage.exe if PowerShell cannot find the command by name.

Confirm that the VM names match KALI-OPS and RANGE-PEER exactly.

Help me inspect both VirtualBox network adapters.

Build the evidence pack

An evidence pack turns terminal output into a repeatable explanation. It records the intended design beside the observations that support it.

  • Create the local evidence folder in Windows PowerShell by running this command:
New-Item -Path 'C:\CyberRange\Project-1-Isolation' -ItemType Directory -Force

What does this command create?

The command creates C:\CyberRange\Project-1-Isolation for your screenshots and Markdown files. The force option keeps the command safe to rerun if the folder already exists.

Capturing terminal proof can feel fiddly because the useful lines may be spread across the scrollback. Save each result separately so every important line remains readable.

  • Return to the Kali terminal containing the final results.
  • Press Windows+Shift+S to begin a screen capture.
  • Drag over the first Kali result.
  • Open the capture preview from the Windows notification area.
  • Press Ctrl+S to save the capture.
  • Save the capture inside C:\CyberRange\Project-1-Isolation.
  • Repeat the capture flow for the remaining Kali results and the Alpine address output.
  • Repeat the capture flow for each VirtualBox VM report in PowerShell.

What your screenshots establish

  • The Kali captures show its address, connected route, successful ping, and missing IPv4 default route.
  • The Alpine capture shows the peer address on the same subnet.
  • The VirtualBox captures show both adapters attached to range-lan.
  • Press the Windows key to open search.
  • Search for Notepad and press Enter.
  • Write a two-node architecture sketch showing KALI-OPS and RANGE-PEER connected through range-lan.
  • Add the 10.10.10.0/24 IP plan with 10.10.10.10/24 for KALI-OPS.
  • Add 10.10.10.20/24 for RANGE-PEER.
  • Press Ctrl+Shift+S to open the save dialog.
  • Enter C:\CyberRange\Project-1-Isolation\README.md in the File name field.
  • Select All files under Save as type.

Keep the architecture readable

Use short labels in your sketch. A clear line between the two VM names through range-lan makes the permitted path easy to explain.

  • Select Save to create README.md.
  • Press Ctrl+N to start a new Notepad document.
  • Copy your authorized local-only scope statement from Step 0 into the new document.
  • Save the scope document as C:\CyberRange\Project-1-Isolation\rules-of-engagement.md.
  • Press Ctrl+N to start the evidence notes.
  • Record your NAT baseline observations in the notes.
  • Record the missing guest addresses you observed after moving to Internal Networking.
  • Record the static IPv4 configuration that restored peer communication.

Connect the observation to the fix

Your notes should preserve the sequence of evidence. The baseline shows the starting behavior before the isolated network removed automatic addressing.

The static configuration then explains why peer communication returned without an external gateway. This sequence makes the lab result reproducible.

  • Record the successful three-reply ping from KALI-OPS to 10.10.10.20.
  • Record the connected 10.10.10.0/24 route shown by Kali.
  • Record that Kali has no IPv4 default route.
  • Save the notes as C:\CyberRange\Project-1-Isolation\evidence-notes.md.

Before the final check, consider whether the completed folder should now resolve as an existing Windows path.

  • Return to Windows PowerShell from earlier.
  • Verify that the evidence folder exists by running this command:
Test-Path -Path 'C:\CyberRange\Project-1-Isolation'

What does the path check prove?

The command checks whether Windows can find the evidence folder at the exact project path. A positive result confirms that the package exists on disk.

You should see True in PowerShell. That confirms the evidence folder exists.

  • Press Windows+E to open File Explorer.
  • Enter C:\CyberRange\Project-1-Isolation in the address bar and press Enter.
  • Confirm that README.md contains the two-node architecture and IP plan.
  • Confirm that rules-of-engagement.md contains your authorized local-only scope.
  • Confirm that evidence-notes.md contains the baseline, missing-address observation, static-address fix, successful ping, and routing result.
  • Confirm that the folder contains readable screenshots of every guest and VirtualBox result.

You have turned a working two-node range into a documented isolation test. Your evidence now shows the permitted path and the missing external route.

Secret mission

Quarantine the Peer on a Second Segment

Move RANGE-PEER onto a separate VirtualBox Internal Network while keeping its existing IP address. Prove the hypervisor boundary blocks communication before returning the peer safely to range-lan.

Clean Up Your Resources

Clean Up Your Resources

Your lab runs locally in Oracle VirtualBox, so it creates no service charges. Pick the option that matches whether you are continuing now, returning later, or removing the disposable peer.

Resources you used:

  • The temporary RANGE-PEER virtual machine includes its 1 GB dynamically allocated virtual disk.
  • The verified alpine-virt-3.24.1-x86_64.iso live image boots Alpine Linux for the peer.

What About the Internal Networks?

Oracle VirtualBox creates named Internal Networks automatically when VM adapters need them.

The range-quarantine network has no final attachment, so it needs no separate cleanup. The range-lan network stays attached to KALI-OPS for later lab work.

Keep everything running

Keep the current lab state while you are actively testing. Both guests consume host memory when running, but they create no service charge.

  • Leave both guests running only while you are using the range.
  • Preserve the current range-lan attachment for both guests.
  • Retain the verified alpine-virt-3.24.1-x86_64.iso live image.
  • Retain the evidence pack at C:\CyberRange\Project-1-Isolation.

Pause - I'll come back to this later

Shutting down the guests frees host memory while preserving the lab for your next session.

  • Shut down KALI-OPS from the Kali desktop.
  • Shut down RANGE-PEER from its Alpine console.
  • Keep both virtual machine registrations in Oracle VirtualBox Manager.
  • Retain the verified alpine-virt-3.24.1-x86_64.iso live image.
  • Retain the evidence pack at C:\CyberRange\Project-1-Isolation.
  • Reapply 10.10.10.20/24 to the identified Ethernet interface after restarting RANGE-PEER.

The KALI-OPS virtual machine keeps its static NetworkManager profile. The RANGE-PEER virtual machine loses its temporary live-session address when it shuts down.

Delete - I don't want to use this again

Remove the disposable peer resources when you no longer need this lab configuration. Keep KALI-OPS and the evidence pack for the Windows Server follow-on.

  • Shut down RANGE-PEER from its Alpine console.
  • Select RANGE-PEER in Oracle VirtualBox Manager's machine list.
  • Start the virtual machine removal flow from RANGE-PEER's context menu.
  • Include the virtual machine files in the removal so the 1 GB virtual disk is deleted.
  • Confirm RANGE-PEER no longer appears in Oracle VirtualBox Manager.

Good work. The disposable virtual machine and its disk are now gone.

  • Press the Windows key to open the search bar.
  • Type File Explorer and press Enter to open it.
  • Use the File Explorer search box to find alpine-virt-3.24.1-x86_64.iso.
  • Delete alpine-virt-3.24.1-x86_64.iso.
  • Confirm alpine-virt-3.24.1-x86_64.iso no longer appears in the search results.

The KALI-OPS virtual machine remains registered for later lab work. Your evidence pack remains at C:\CyberRange\Project-1-Isolation.

Nice Work!

Nice Work!

You pulled it off! You've built a documented two-node cyber range in VirtualBox that demonstrates deliberate isolation between systems you own and control.

What you learned:

  • Built a two-node local cyber range that runs KALI-OPS beside RANGE-PEER within the 8 GB Windows host limit.
  • Established a named Internal Network boundary on range-lan. Observed the loss of automatic addressing after isolation. Restored peer traffic with static IPv4 addressing while keeping the IPv4 default route absent.
  • Produced a portfolio-ready evidence pack that proves permitted ICMP traffic between the guests. It also proves the absence of an external default route. The pack documents your architecture, authorized scope, IP plan, and test results.
  • Secret Mission: Proved network segmentation by moving RANGE-PEER to range-quarantine. Communication stopped across the separate segments. It returned after the peer rejoined range-lan.

Ready to quiz yourself?