Module 19 Lesson 1 of 6 🕑 ~60 min

> cat module-19-1-planning-your-lab.md

Planning Your Lab

Before installing a single virtual machine, decide what you're actually building and why. This lesson sets the architecture, the hardware budget, the hypervisor, and the firewall everything else in the module will sit behind.

1 Why Build a Home Lab?

A theoretical approach to "I can log into Windows but I can't access the file server" jumps straight to permissions. Someone with practical lab experience asks: can the client resolve the server hostname? Can it reach the server IP? Is the computer still connected to the domain? Did Kerberos authentication succeed? Is the user's group membership correct? Is SMB available? Is the firewall allowing the connection? Is the file server online? What do the Windows event logs show? Is the problem affecting one user or everyone?

Building a lab develops exactly this type of thinking — you can't ask most of those questions convincingly until you've watched the answer change as you break and fix the thing yourself.

2 The Lab Architecture

Imagine you're building infrastructure for a fictional company: Cyber Security Cafe Ltd, internal domain corp.cybersecuritycafe.lab (never use somebody else's real internet domain for this). An example environment, evolving through this module:

Internet
   |
pfSense Firewall
   |
   +-----------------------+
   |                       |
SERVER VLAN             CLIENT VLAN
10.10.10.0/24           10.10.20.0/24
   |                       |
DC01                    WIN11-01
DC02                    WIN11-02
LINUX01
SQL01
SPLUNK01
DOCKER01
       |
   SECURITY VLAN
   10.10.30.0/24
       |
   KALI01
   VULN01

A more advanced build can later add a Management VLAN, DMZ, Database VLAN, Monitoring VLAN, guest network, and cloud network — this is where network segmentation starts to feel real instead of theoretical, because everything isn't sitting on one flat network anymore.

3 Hardware Requirements

You don't need enterprise servers. A reasonably modern desktop or laptop can run several VMs.

  • Entry-level (4+ cores, 16 GB RAM, 250–500 GB SSD): run a few machines at once — e.g. DC01 (2 GB), Windows 11 (4 GB), Linux (2 GB), pfSense (1 GB).
  • Recommended (8+ cores, 32 GB RAM, 1 TB SSD/NVMe): practical for 2 Domain Controllers, 2 Windows clients, a Linux server, pfSense, a database, Splunk, Kali, and Docker all running together.
  • Advanced (12–24 cores, 64–128 GB RAM, 2+ TB NVMe): room to experiment with multiple Windows servers, Kubernetes, multiple databases, SIEM infrastructure, vulnerability scanners, multiple networks, enterprise applications, PKI, and high availability.

Remember that production sizing is very different from home-lab sizing — Splunk's own reference architecture describes substantially higher resources for production workloads than you'd ever allocate to a learning VM. Don't chase production specs; chase enough resources to run the lesson you're on.

4 Choosing a Hypervisor

A hypervisor runs multiple virtual computers on one physical computer. You have real options, and the "right" one depends on what you're trying to learn:

  • Hyper-V — particularly useful for Windows administration, Active Directory and Microsoft infrastructure. Learn virtual switches, virtual disks, checkpoints, memory/CPU allocation, network adapters, ISO mounting, and VM generation.
  • VMware (Workstation, Fusion, ESXi, vSphere, vCenter) — historically extremely common in enterprise environments. Even as companies migrate away from it, understanding VMware terminology stays useful because enormous amounts of legacy infrastructure still runs on it.
  • VirtualBox — convenient for smaller labs, and a good place to learn NAT networking, bridged networking, host-only networking, virtual disks, snapshots, and virtual NICs.
  • Proxmox VE — a good choice if you have a dedicated PC or mini-PC. Introduces Type-1 virtualisation, web-based management, VM templates, snapshots, Linux containers, storage pools, bridges, clustering, and backups.

5 Virtual Networking & Installing pfSense

Before creating dozens of machines, understand three common virtual network modes: NAT (the VM reaches the internet through the host — fine for downloading updates and software), bridged (the VM appears directly on the physical network, e.g. alongside your router and laptop on 192.168.1.0/24 — useful sometimes, but never for deliberately vulnerable machines), and isolated/internal (VMs talk to each other without being exposed to the household or corporate network at all — extremely useful for cybersecurity labs, e.g. separate 10.10.10.0/24, 10.10.20.0/24 and 10.10.30.0/24 segments with a virtual firewall controlling traffic between them).

Install pfSense as the lab firewall so the environment starts behaving like a real company network, not a flat pile of VMs:

WAN
 |
pfSense
 |
 +--- SERVER
 |
 +--- CLIENT
 |
 +--- SECURITY

Configure interfaces, IP addressing, DHCP, DNS forwarding, NAT, firewall rules, network aliases, and logging — and later, VLANs, VPNs, port forwarding, DNS filtering, and traffic monitoring. The important lesson isn't the pfSense interface itself; it's this principle: traffic should only be allowed when there is a business requirement for it. For example: client → domain controller DNS, allowed; client → domain controller Kerberos, allowed; client → database, blocked; application server → database, allowed. That's segmentation and least privilege, in miniature, before you've built a single server.