How to Configure VirtualBox networks for Secure Cybersecurity Lab (Step-by-Step Guide)

Introduction

Network misconfiguration is the #1 reason beginner hacking labs break — either the attacker VM can't reach the target, the target leaks onto your real LAN, or Kali loses internet access mid-session. [ 1 ] VirtualBox has six distinct network modes, each with completely different behaviour. Choosing the wrong one either kills your lab connectivity or — worse — accidentally exposes a vulnerable VM to your home network.

This guide gives you a complete understanding of every mode, the exact configuration steps for three lab topologies, and a CLI reference for scripting your setup.

All Six VirtualBox Network Modes Explained

Deep Dive: Each Mode Explained

NAT (Default)

NAT is the out-of-the-box default — every new VM uses it. VirtualBox creates a virtual router inside the host, assigns the VM an IP in the 10.0.2.0/24 range, and translates outbound traffic through the host's real connection. [ 2 ]

The critical limitation: Each VM gets its own completely separate NAT router. Two VMs both on NAT mode cannot communicate with each other even though they look identically configured. This is why your ping between Kali and Metasploitable fails if both are on default NAT. [ 2 ]

NAT Network [Recommended for Most Labs]

NAT Network is NAT shared between multiple VMs — all VMs join the same virtual router, can reach each other, and share a single NAT exit to the internet. This is the best choice for a Kali + Metasploitable lab where you want internet on Kali but full isolation from your real LAN. [ 2 ]

Host-Only Adapter

Host-Only creates a virtual network card on your host machine (shown as VirtualBox Host-Only Ethernet Adapter in Windows, vboxnet0 on Linux) that bridges the host and all VMs. VMs can talk to each other and to the host, but have no route to the internet.

Best use case: When you want to SSH into a VM from your host terminal, or share files easily between host and VM without internet exposure.

Internal Network [Maximum Isolation]

Internal Network is the most locked-down mode — VMs can only talk to other VMs on the same named network. The host cannot see them, there is no internet, no DHCP unless you configure it manually.

Best use case: Malware analysis labs, or when practicing with exploits you don't want to accidentally escape your VM boundary.

Bridged Adapter [Dangerous for Vulnerable VMs]

Bridged mode connects the VM directly to your physical network card — the VM gets its own IP from your real router's DHCP and appears as a full device on your LAN. [ 2 ]

Never use Bridged mode for Metasploitable or any intentionally vulnerable VM. Every device on your home Wi-Fi can reach it.

Three Lab Topologies — Step-by-Step Configuration

Topology 1: NAT Network (Recommended Beginner Setup)

Best for:Metasploitable with internet access on Kali. [ 5 ]

Step 1 — Create the NAT Network

Via GUI:

Via CLI (VBoxManage):

# Create the NAT Network named HackLab
VBoxManage natnetwork add \
  --netname HackLab \
  --network "10.10.10.0/24" \
  --enable \
  --dhcp on

# Verify it was created
VBoxManage natnetwork list

Step 2 — Assign VMs to HackLab

# Assign Kali to HackLab NAT Network
VBoxManage modifyvm "Kali Linux" \
  --nic1 natnetwork \
  --nat-network1 "HackLab"

# Assign Metasploitable to HackLab NAT Network
VBoxManage modifyvm "Metasploitable2" \
  --nic1 natnetwork \
  --nat-network1 "HackLab"

Or via GUI: VM ⟶ Settings ⟶ Network ⟶ Adapter 1 ⟶ Attached to: NAT Network ⟶ Name: HackLab

Step 3 — Add Internet Adapter to Kali Only

Give Kali a second adapter for internet access (tool updates, research) while keeping its lab interface on HackLab: [ 2 ]

VBoxManage modifyvm "Kali Linux" \
  --nic2 nat

Or GUI: Kali Settings ⟶ Network ⟶ Adapter 2 ⟶ Enable ⟶ Attached to: NAT

Final Topology:

Kali Linux
  eth0  ⟶ 10.10.10.x    (HackLab — attacks go here)
  eth1  ⟶ 10.0.2.15     (NAT — internet access)

Metasploitable 2
  eth0  ⟶ 10.10.10.y    (HackLab — target)
  [no internet access]

Topology 2: Internal Network (Maximum Isolation)

Best for: Malware analysis, exploit development, fully air-gapped practice. [ 4 ]

Step 1 — Configure Internal Network on Both VMs

Via CLI:

VBoxManage modifyvm "Kali Linux" \
  --nic1 intnet \
  --intnet1 "IsolatedLab"

VBoxManage modifyvm "Metasploitable2" \
  --nic1 intnet \
  --intnet1 "IsolatedLab"

Internal Network has no built-in DHCP — you must assign static IPs manually.

Step 2 — Assign Static IPs Inside Each VM

On Kali Linux:

# Temporary (until reboot)
# Manually assigns the IP address
sudo ip addr add 10.20.20.10/24 dev eth0
# Turns on (activates) the eth0 network interface
sudo ip link set eth0 up

# Permanent (Kali uses NetworkManager)
# Edits the saved network profile called "Wired connection 1" in NetworkManager
sudo nmcli connection modify "Wired connection 1" \
  ipv4.addresses "10.20.20.10/24" \
  ipv4.method manual
# Applies and activates the updated network profile immediately
sudo nmcli connection up "Wired connection 1"

On Metasploitable 2:

# Temporary
sudo ifconfig eth0 10.20.20.20 netmask 255.255.255.0 up

# Permanent (edit interfaces file)
sudo nano /etc/network/interfaces

Add to /etc/network/interfaces:

auto eth0
iface eth0 inet static
    address 10.20.20.20
    netmask 255.255.255.0

Step 3 — Add Internet Adapter to Kali (Optional)

# Add NAT as Adapter 2 for internet on Kali only
VBoxManage modifyvm "Kali Linux" \
  --nic2 nat

Test Connectivity:

# From Kali
ping 10.20.20.20 -c 3      # Should succeed
ping 8.8.8.8 -c 3          # Should succeed (via eth1)

# From Metasploitable
ping 10.20.20.10 -c 3      # Should succeed
ping 8.8.8.8 -c 3          # Should FAIL — fully isolated

Topology 3: Host-Only + NAT (Access VMs from Host Terminal)

Best for: When you want to SSH into your VMs from your main machine's terminal (VS Code Remote SSH, Windows Terminal, etc.). [ 2 ]

Step 1 — Create a Host-Only Network

Via CLI:

# Create host-only network
VBoxManage hostonlyif create

# Configure IP on the host-only interface
VBoxManage hostonlyif ipconfig vboxnet0 \
  --ip 192.168.56.1 \
  --netmask 255.255.255.0

# Enable DHCP on it
VBoxManage dhcpserver add \
  --ifname vboxnet0 \
  --ip 192.168.56.100 \
  --netmask 255.255.255.0 \
  --lowerip 192.168.56.101 \
  --upperip 192.168.56.254 \
  --enable

Step 2 — Assign Adapters to Kali

# Adapter 1: Host-Only (SSH from host, VM-to-VM)
VBoxManage modifyvm "Kali Linux" \
  --nic1 hostonly \
  --hostonlyadapter1 "vboxnet0"

# Adapter 2: NAT (internet access)
VBoxManage modifyvm "Kali Linux" \
  --nic2 nat

Step 3 — SSH Into Kali from Host

# From your host machine (Windows Terminal / Linux terminal)
ssh kali@192.168.56.101

# Or from VS Code: Remote SSH  ⟶ 192.168.56.101

Dual-Adapter Configuration Reference

What Is a Dual-Adapter Setup?

A dual-adapter setup means assigning two separate virtual network interface cards (NICs) to a single VM — each connected to a different network — so the VM can handle two different types of traffic simultaneously.

For the most practical lab setup, Kali uses two adapters simultaneously:

Prerequisites

Before starting, confirm the following are ready:

[ ] VirtualBox installed (6.x or 7.x)
[ ] Kali Linux VM imported and visible in VirtualBox Manager
[ ] Metasploitable2 VM imported and visible
[ ] HackLab NAT Network already created
[ ] Both VMs are powered OFF

Verify HackLab NAT Network exists:

VBoxManage natnetwork list

Expected output:

Name:        HackLab
Network:     10.10.10.0/24
Gateway:     10.10.10.1
DHCP:        Yes
Enabled:     Yes

If HackLab doesn't exist yet, create it first:

VBoxManage natnetwork add \
  --netname HackLab \
  --network "10.10.10.0/24" \
  --enable \
  --dhcp on

PART 1 — Configure Kali Linux (Dual Adapter)

Step 1A — Set Adapter 1 ⟶ NAT Network (HackLab)

GUI Method:

CLI Method:

# Power off Kali first
VBoxManage controlvm "Kali Linux" poweroff

# Assign Adapter 1 to HackLab NAT Network
VBoxManage modifyvm "Kali Linux" \
  --nic1 natnetwork \
  --nat-network1 "HackLab"

Configuring Port Forwarding on NAT Network

Port Forwarding on NAT Network is a rule that redirects traffic from your host machine's port to a specific VM's port — allowing you to reach services running inside a VM from outside it.

Why It's Needed

In NAT/NAT Network mode, the VM is hidden behind the virtual router — the host and external machines can't directly reach the VM. Port forwarding punches a specific "door" through that router.

How It Works — Step by Step

How to Configure — GUI

How to Configure — VBoxManage CLI

# Forward host port 2222 → Kali SSH (port 22)
VBoxManage natnetwork modify \
  --netname HackLab \
  --port-forward-4 "KaliSSH:tcp:[]:2222:[10.10.10.4]:22"

# Forward host port 8080 → Metasploitable HTTP (port 80)
VBoxManage natnetwork modify \
  --netname HackLab \
  --port-forward-4 "MetasploitHTTP:tcp:[]:8080:[10.10.10.5]:80"

# Then access from host:
# ssh -p 2222 kali@127.0.0.1
# http://127.0.0.1:8080

Port forwarding gives you controlled access — only the ports you explicitly forward are reachable, making it safer for lab environments.[simplified] ​

Advanced: Multi-Subnet Lab with Virtual Router

For advanced practice simulating real enterprise networks with multiple network segments — add a third VM running pfSense or VyOS as a virtual router between subnets: [ 7 ]

This forces you to practice pivoting — compromising a machine in LAN1 to reach LAN2, which mirrors real penetration testing engagements.

Conclusion

Your VirtualBox network is now precisely configured — not just working, but properly understood. You no longer have to guess why your VMs can't ping each other or worry that a vulnerable machine is quietly exposed to your home network.

The One Rule That Solves 90% of Lab Problems

Every VirtualBox network issue you will ever encounter traces back to this single principle:

Default NAT  =  each VM gets its own isolated router
               → two VMs on NAT CANNOT talk to each other

NAT Network  =  all VMs share one virtual router
               → VMs CAN talk to each other + internet on Kali

Internal Network = no DHCP, no internet, no host access
               → assign static IPs manually for max isolation

When your lab breaks, always check this first — wrong mode is the #1 cause of every beginner connectivity failure.

Network configuration is invisible when it works and catastrophic when it doesn't. Now you understand every mode, every topology, and exactly what to do when something breaks.

You went from "why can't my VMs ping each other?" to having a fully documented, scriptable, secure, multi-topology lab network — the same level of understanding a professional penetration tester uses when building client lab environments.

Your lab is properly isolated. Your Kali has internet. Your Metasploitable is locked down. Start hacking.