Building a Virtualized Cybersecurity Lab: Networking and pfSense Setup

The Reason Why

Over the past year, I’ve used individual virtual machines, Docker containers, and online training platforms like TryHackMe to build hands-on cybersecurity experience. Although these tools are valuable, they don’t provide the realism or complexity of working inside a fully controlled network environment. With the start of my Cyber Security degree at Maryville University—and after moving my main workstation to a Fedora-based Linux distribution when Windows 10 reached end of life—I decided it was the right time to build a proper virtualized homelab. Running Linux as my host OS also let me avoid Windows 11’s hardware requirements such as Secure Boot and TPM, giving me full control over my virtualization stack and allowing me to design an enterprise-style lab tailored specifically for cybersecurity training.

This post is the first entry in a four-part series documenting my homelab build. Here, I cover the foundational architecture choices, explain how I configured the virtualization environment, and walk through the process of deploying pfSense as the core router and firewall for the entire network. Because my workstation runs Linux natively, I chose KVM and QEMU for their performance, flexibility, and deep integration with the OS. Combined with libvirt, virsh, and virt-viewer, this gives me a fast, lightweight, and highly customizable virtualization ecosystem—ideal for learning how real infrastructure operates behind the scenes.

My Lab Is Organized Around Four Primary Components:

1. Virtual Networks lab-NAT – Provides pfSense with upstream internet access through the Linux host. lab-LAN – A fully isolated internal network where all client and server VMs live.

This separation models a real enterprise network with distinct external and internal segments.

1. pfSense Firewall/Router pfSense serves as the central security appliance of the lab, providing:
2. Routing between WAN and LAN
3. Stateful firewalling
4. DHCP services
5. NAT translation
6. Segmentation and network boundary control

All traffic entering or leaving the internal network passes through pfSense, mirroring the design of most corporate environments.

1. Internal Systems These are the systems that make up the “enterprise network” inside the lab: Windows Server 2022 (Active Directory + DNS) Windows 11 workstation Ubuntu Desktop running Splunk Additional Linux servers for testing and future projects

This provides a functional identity, endpoint, and logging ecosystem that represents a realistic enterprise environment.

1. External Attack Machine (Kali ThinkPad via VPN) In addition to the internal VMs, I’m integrating my physical Kali Linux ThinkPad as an external attacker machine. I connect it to the pfSense firewall through a VPN tunnel, simulating either: an external threat actor accessing the network from outside, or a rogue device connecting through a controlled entry point.

This setup allows me to perform penetration testing, vulnerability discovery, and attack simulations against the isolated lab-LAN—while keeping everything safely contained and segmented from my real devices.

Process Overview

For readers who want insight into how I approached the build, I’ve included an overview of the major configuration steps I performed. Readers don't have to read every detail, this is more a summary of the important actions supported by screenshots to document the process.

Section 1 — Preparing the Virtualization Stack

Installing KVM/QEMU and Tools

sudo rpm-ostree install @virtualization virt-manager libvirt libvirt-daemon-kvm qemu-kvm bridge-utils --allow-inactive

What this stack provides:

KVM/QEMU: hardware-accelerated virtualization
libvirt: management layer for VMs
virsh: CLI tool for creating and controlling VMs
virt-manager / virt-viewer: optional GUI tools

Enable and Start libvirt

sudo systemctl enable --now libvirtd

Verify:

sudo systemctl status libvirtd

Verify KVM Support

egrep -c '(vmx|svm)' /proc/cpuinfo

Section 2 — Creating the Virtual Networks

My homelab will use two networks:
lab-NAT (WAN side)
Connects pfSense to the internet
Uses NAT from the Linux host
lab-LAN (internal network)
Hosts all internal machines
Completely isolated from the host
pfSense handles all routing and DHCP

Example XML for lab-LAN and lab-NAT:

Define and start the lab-lan after creating its XML file:

sudo virsh net-define /etc/libvirt/qemu/networks/lab-lan.xml
sudo virsh net-start lab-lan
sudo virsh net-autostart lab-lan

this process is mostly the same for creating the lab-nat

Verify by listing all networks running:

Section 3 — Deploying pfSense (The Core of the Lab)

pfSense is the heart of the homelab and acts as:
Router
Firewall
DHCP server
Gateway for the lab-lan virtual network
Segmentation control
This mirrors what most corporate networks use.

Creating the pfSense VM with Virt Install

sudo virt-install \
  --name pfSense \
  --ram 2048 \
  --vcpus 2 \
  --os-variant freebsd13.0 \
  --disk path=/var/lib/libvirt/images/pfSense.qcow2,size=10,format=qcow2 \
  --cdrom /var/lib/libvirt/boot/pfsense.iso \
  --network network=lab-nat,model=virtio \
  --network network=lab-lan,model=virtio \
  --graphics spice \
  --boot uefi

Open installer:

sudo virt-viewer pfSense

pfSense Interface Assignment
pfSense will detect and ask you to confirm the LAN and WAN:
vtnet0 → WAN (lab-NAT)
vtnet1 → LAN (lab-LAN)
Set the LAN IP
I assigned a memorable static IP to the pfSense LAN interface for easier VM configuration and future reference:
Class A starting with 10.0.0.1
and a subnet mask of 255.255.255.0 gives me plenty of room for my small network
LAN IP: 10.0.0.1/24
DHCP range: 10.0.0.50–10.0.0.200
After this point, pfSense becomes the router and firewall.
Every VM ill attach to lab-lan receives:
IP: 10.0.0.x
Gateway: 10.0.0.1
DNS: 10.0.0.1
Internet routed through pfSense

This completes the initial network segmentation and routing.

Key Takeaways / Lessons Learned

Building the firewall and virtual networking foundation for my homelab significantly improved my confidence with virsh, virt-viewer, and KVM-based virtualization. This phase reinforced key infrastructure concepts such as defining virtual networks, bridging interfaces, configuring routing, and assigning DHCP at the firewall layer. Deploying pfSense helped deepen my understanding of segmentation, NAT behavior, and multi-interface design. Altogether, these steps gave me hands-on experience creating a network architecture that mirrors what real-world IT and security teams use in production.

Next Steps / Learning Opportunities

With the core networking and firewall components complete, my next goal is to expand pfSense’s capabilities and shift toward a more security-focused environment. I plan to explore advanced firewall rules, VLAN segmentation, DNS resolver tuning, and static DHCP mappings for key hosts. I also want to evaluate pfSense packages including pfBlockerNG for threat intelligence and Suricata for IDS/IPS functionality, adding deeper traffic inspection and detection capability.

In the next post, I’ll move into the identity layer by installing Windows Server 2022, promoting it to a Domain Controller, configuring DNS, and integrating it with pfSense. I will join both Windows and Linux clients to the domain and verify authentication across the environment. This will establish the Active Directory foundation that future posts will build on—covering SOC workflows, blue-team tooling, detection engineering, and attack simulations.