Building a Cyber Range Inside VMware: Proxmox, Metasploitable2, and a Long Saturday

It started as a simple question: is there more than one way to set up a home lab?

The answer, it turns out, is yes — and today I went down that rabbit hole all the way to a running Metasploitable2 target on an isolated network inside a Proxmox hypervisor running inside VMware Workstation on my Debian host. Nested virtualization. Turtles all the way down.

Here’s what I actually accomplished.

The Setup

My existing lab runs on Debian 13 (Trixie) with VMware Workstation 17.6.4 and a collection of VMs — Kali, CSI Linux, Parrot, Red Hat, Ubuntu, and a broken BlackArch install I’m not ready to delete yet. It works. But I wanted to understand what a dedicated hypervisor looks like, and whether I had the hardware to support one.

Turns out I do. My root partition is 1.8TB with 652GB free. Plenty of room to experiment.

Installing Proxmox VE 9.2 Inside VMware

Since I don’t have a spare machine to dedicate to Proxmox right now, I went the nested virtualization route — running Proxmox as a VM inside VMware. Not the production way to do it, but a legitimate way to learn the interface before committing to hardware.

The process:

Downloaded proxmox-ve_9.2-1.iso from proxmox.com
Created a new VMware VM: Debian 64-bit, 4 cores, 4GB RAM, 80GB disk
Attached the Proxmox ISO and enabled nested virtualization in the processor settings
Installed Proxmox through the graphical installer
Set hostname to promox, accepted the auto-detected network config

After install, Proxmox came up at https://192.168.95.134:8006 — the web UI was immediately accessible from my Debian browser.

Cleaning Up the Repos

Fresh Proxmox installs come configured for the enterprise repository, which requires a paid subscription. The fix is straightforward — disable the enterprise sources and add the free community repo:

bash

cat > /etc/apt/sources.list.d/pve-enterprise.sources << 'EOF'
# disabled - no subscription
# Types: deb
# URIs: https://enterprise.proxmox.com/debian/pve
# Suites: trixie
# Components: pve-enterprise
EOF

cat > /etc/apt/sources.list.d/ceph.sources << 'EOF'
# disabled - no subscription
# Types: deb
# URIs: https://enterprise.proxmox.com/debian/ceph-squid
# Suites: trixie
# Components: enterprise
EOF

echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" >> /etc/apt/sources.list
apt-get update && apt-get upgrade -y

Clean update. No more 401 errors.

Importing Metasploitable2

With Proxmox running and updated, the next goal was getting Metasploitable2 — the classic intentionally vulnerable target VM — running inside it.

Downloaded metasploitable-linux-2.0.0.zip from SourceForge, extracted it on the Debian host, then transferred the VMDK to Proxmox via SCP:

bash

scp ~/Downloads/Metasploitable2-Linux/Metasploitable.vmdk root@192.168.95.134:/tmp/

163MB/s. Done in 11 seconds.

Then inside the Proxmox shell:

bash

qm create 100 --name metasploitable2 --memory 512 --net0 virtio,bridge=vmbr0
qm importdisk 100 /tmp/Metasploitable.vmdk local-lvm
qm set 100 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-100-disk-0
qm set 100 --boot c --bootdisk scsi0
qm set 100 --ostype l26
qm set 100 --kvm 0

The --kvm 0 flag was the key — since Proxmox is running inside VMware, hardware KVM acceleration isn’t available. Software emulation works fine for a target VM like Metasploitable.

Setting Up the Isolated Network

Metasploitable is deliberately full of vulnerabilities. It should never touch a real network. In the Proxmox UI I created a second Linux bridge — vmbr1 — with no ports, no gateway, and no CIDR. An air-gapped internal network that exists only inside the hypervisor.

Metasploitable was attached to vmbr1. Since there’s no DHCP on an isolated bridge, I assigned a static IP manually after boot:

bash

sudo ifconfig eth0 192.168.100.2 netmask 255.255.255.0 up

Confirmed with ifconfig:

inet addr: 192.168.100.2   Mask: 255.255.255.0

Metasploitable2 is live at 192.168.100.2 on an isolated internal network.

Where Things Stand

The cyber range is taking shape:

VM	Role	Network	IP
Metasploitable2	Target	vmbr1 (isolated)	192.168.100.2
Kali (next)	Attacker	vmbr1 (isolated)	192.168.100.x

What’s Next

The next session picks up here:

Add Kali to the vmbr1 isolated network inside Proxmox
Assign Kali a static IP on the 192.168.100.x range
Run the first nmap scan against Metasploitable
Start working through exploits with Metasploit Framework

Today was infrastructure. Next time, the actual hacking starts.