A virtualized Small Office / Home Office network built entirely inside VMware Workstation. This project simulates real-world networking and security infrastructure at a smaller scale — a safe sandbox to break things, learn from them, and build something solid.
Most networking knowledge lives in documentation and theory. This lab is the hands-on counterpart — every service, every firewall rule, every DNS record configured from scratch, the same way it would be done on real hardware.
The goal is not just to make things work, but to understand why they work. When something breaks — and it will — the debugging process teaches more than any tutorial.
Internet
│
┌──────▼──────┐
│ pfSense │
│ Firewall │ 192.168.1.1
│ Router │
│ DHCP │
└──────┬──────┘
│
LAN — 192.168.1.0/24
│
┌──────────────────┼───────────────────┐
│ │ │
┌───────▼───────┐ ┌───────▼───────┐ ┌────────▼──────┐
│ Services VM │ │ VPN VM │ │ Dev Server │
│ 192.168.1.2 │ │ 192.168.1.3 │ │ 192.168.1.4 │
│ │ │ │ │ │
│ Pi-hole DNS │ │ WireGuard │ │ Docker │
│ Nginx Proxy │ │ OpenVPN │ │ Applications │
└───────────────┘ └───────────────┘ └───────────────┘
| Layer | Tool | Purpose |
|---|---|---|
| Firewall / Router | pfSense | Traffic control, DHCP, NAT, firewall rules |
| DNS | Pi-hole | Network-wide DNS, ad blocking, local records |
| Reverse Proxy | Nginx Proxy Manager | Local domain routing, SSL termination |
| VPN | WireGuard | Remote access into the lab network |
| VPN | OpenVPN | Enterprise-style VPN, learning alternative |
| Runtime | Docker + Compose | Application containers on dev server |
| Remote Dev | VSCode Remote SSH | Edit server files directly from client machine |
| Hypervisor | VMware Workstation Pro | Hosts all VMs on a single Windows machine |
All services are accessible by domain name inside the network via Pi-hole DNS and Nginx reverse proxy.
| Domain | Service |
|---|---|
pfsense.home.lab |
pfSense dashboard |
pihole.home.lab |
Pi-hole admin panel |
nginx.home.lab |
Nginx Proxy Manager UI |
vpn.home.lab |
VPN server |
dev.home.lab |
Dev server applications |
pfSense deployed with two network interfaces — WAN on NAT, LAN on an isolated internal VMware network. Handles all routing, DHCP, and firewall rules. No other service works without this in place.
Pi-hole deployed as the network DNS server in Docker with host networking mode to correctly receive LAN queries. All DHCP clients get Pi-hole as their DNS automatically via pfSense. Nginx Proxy Manager deployed alongside Pi-hole on the same VM, routing local domains to the right service.
WireGuard and OpenVPN both deployed on a dedicated Debian VM. Accessing the lab from outside the network over an encrypted tunnel — same principle as corporate VPN. DuckDNS handles dynamic IP so the hostname always resolves regardless of ISP IP changes.
Headless Debian VM with Docker. Projects cloned from Git, deployed as containers, accessible on the LAN by IP and port. VSCode Remote SSH used to edit files directly on the server from a client machine — no file transfers, no syncing.
- Network segmentation and firewall rule design
- DHCP and DNS configuration and their relationship
- Reverse proxying and local SSL
- Containerisation with Docker and Docker Compose
- VPN server setup from scratch — key generation, peer config, tunnel routing
- SSH key authentication and secure remote access
- Headless Linux server administration over SSH
This lab is built to mirror real hardware 1:1. When ready, each VM maps directly to a physical machine:
| VM | Physical Equivalent |
|---|---|
| pfSense VM | Mini PC with two NICs (e.g. Protectli) |
| Services VM | Raspberry Pi or low-power mini PC |
| VPN VM | Any always-on Linux machine |
| Dev Server | Old desktop or mini PC |
Configs, IPs, and architecture stay identical — just move each VM's setup to its physical counterpart.
VMware Workstation Pro allows granular control over virtual networks — creating isolated internal networks, NAT interfaces, and custom subnets that behave exactly like physical network segments. This makes it the closest simulation of real infrastructure without buying hardware.
A few things this lab made concrete that documentation alone doesn't:
- DNS is everything. Most connectivity problems trace back to DNS misconfiguration. Getting Pi-hole to correctly serve LAN queries — especially inside Docker — required understanding how containers see the network versus how the host sees it.
- Firewall rules are explicit. pfSense blocks everything by default. Nothing works until a rule says it should. This is correct behaviour, not a bug.
- Docker networking adds a layer. Services inside containers don't automatically see the host network.
network_mode: hostandhost.docker.internalexist to bridge this gap and knowing when to use each matters. - SSH keys are non-negotiable. Setting them up once and never typing a password again is not just convenience — it is the correct security posture.
/
├── docs/
│ ├── troubleshooting-dns-proxy.md
│ ├── dev-server-setup.md
│ └── ssh-vscode-remote.md
├── services-vm/
│ └── docker-compose.yml ← Pi-hole + Nginx Proxy Manager
├── vpn-vm/
│ └── wg0.conf ← WireGuard server config
└── README.md
| Phase | Status |
|---|---|
| Phase 1 — pfSense + Networking | ✅ Complete |
| Phase 2 — Pi-hole + Nginx | ✅ Complete |
| Phase 2.5 — WireGuard + OpenVPN | 🔄 In Progress |
| Phase 3 — Dev Server + Docker | ✅ Complete |
| Phase 4 — Storage + Monitoring | 🔄 In Progress |
| Phase 5 — VLANs + Hardening | ⏳ Planned |
| Bare Metal Migration | ⏳ Planned |