A Proxmox lab in the cloud for cert study: sizing, networks and access
A firewall, a Windows server and a couple of Linux boxes on networks you control, running around the clock. How we built ours on Proxmox VE, sized for a VPS.
A lab for firewall, Windows Server or Linux certifications needs a handful of VMs on networks you control, running around the clock and reachable from wherever you study. A Proxmox VE node in the cloud does that without a server humming in your closet. This is how we built ours, sized down to what fits in 12 GB.
- What fits in the memory you have
- Lab networks: one NAT bridge, a few isolated ones
- Firewall appliances, Windows and Linux guests
- Getting to the lab from home
- Checkpoints before you break things
What fits in the memory you have
Memory runs out long before CPU in a lab. Proxmox itself idles at about 1.5 GB. Starting points for the guests:
| VM | Memory to start with | Notes |
|---|---|---|
| Proxmox VE itself | about 1.5 GB | Before any VM starts |
| Firewall / router appliance | 2 GB | Our FortiGate lab VM runs in 1 vCPU and 2 GB; check your vendor’s minimum |
| Windows Server (Desktop Experience) | 4 GB | Domain controller, DNS, a CA — one VM can do all three in a lab |
| Small Linux server or client | 1 GB each | Debian or Ubuntu cloud images |
That's a firewall, a Windows server and two Linux VMs in about 9.5 GB, which leaves headroom on a 12 GB node. On 8 GB, run the firewall with either the Windows server or up to three Linux VMs, not all of them at once; 4 GB is enough for Proxmox and one or two small VMs, not a full lab. Run only what today's topic needs — a stopped VM uses no memory.
Lab networks: one NAT bridge, a few isolated ones
Keep the bridge that gives VMs internet access (on our nodes, vmbr1 on 192.168.100.0/24, set up by our NAT guide), and add isolated bridges for the networks behind your firewall. An isolated bridge has no physical port and no address on the node, so the only way across is through the firewall VM — exactly what you want to practise.
auto vmbr2
iface vmbr2 inet manual
bridge-ports none
bridge-stp off
bridge-fd 0
auto vmbr3
iface vmbr3 inet manual
bridge-ports none
bridge-stp off
bridge-fd 0Apply with ifreload -a. Give the firewall VM one network card per bridge (its "outside" on vmbr1, "inside" on vmbr2, DMZ on vmbr3), and point the client VMs' gateway at the firewall's inside address.
Edited the file by hand? Delete any leftover /etc/network/interfaces.new before your next reboot — it can replace your file.
Firewall appliances, Windows and Linux guests
Firewall and router appliances
Vendors ship KVM images (usually qcow2); import one as a VM disk with qm importdisk. Many can take their first-boot configuration from a config drive: we bootstrapped our FortiGate VM by passing its CLI config as user data through Proxmox's cicustom setting with the Cloud-Init drive type configdrive2. Use the vendor's evaluation images and follow their license terms.
Windows Server
- We used a SATA disk and an Intel E1000E network card, which Windows Setup supports out of the box — no VirtIO driver disk to load mid-install.
- Evaluation editions need to activate online. Install on the NAT bridge so the VM has internet, and move it to an isolated segment afterwards.
- Windows Firewall drops ping by default, so a VM that doesn't answer ping may be fine. Check it with
ip neighon a neighbour, or the Proxmox console.
Linux guests
- Debian and Ubuntu cloud images with Proxmox's Cloud-Init drive give you a configured VM in a minute: set the address with
qm set <vmid> --ipconfig0 ip=…,gw=…, thenqm cloudinit update <vmid>. - Changing the Cloud-Init network and restarting gives the VM a new instance ID, so cloud-init runs again — including new SSH host keys. Expect a host-key warning afterwards.
- If you script it:
cloud-init status --waitexits with status 2 on mere warnings, which silently stops a script running underset -e.
Getting to the lab from home
- The Proxmox web UI console works for every VM with no extra setup — the quickest way in when a lab network is down.
- Port forwards reach single services (SSH to a jump box, a firewall's web UI) — see forwarding a port to a VM, and open the outside port in your provider's firewall.
- WireGuard on the node gives you the whole lab as if you were on site: route the lab subnets over the tunnel and exempt them from the NAT bridge's masquerading, or replies come back rewritten (how).
Networks behind your firewall VM are only reachable through it. If you don't want to spend firewall rules on routing them to your VPN, use the Proxmox console or qm guest exec (with the guest agent installed) to work inside them.
Checkpoints before you break things
Labs are for breaking things, so take checkpoints. Use qcow2 as the disk format for lab VMs: on directory storage that's what makes Proxmox's own VM snapshots available, so you can roll a VM back to a known-good state. Proxmox's backup (vzdump) to local storage covers the rest.
On our VPS, a Piedmont snapshot of the whole node ends with a forced power-off and restart, which hard-stops every VM inside it. For lab checkpoints, use Proxmox's VM snapshots instead.