Building a segmented GOAD red team lab on Proxmox and pfSense

A build guide that stands up the GOAD Active Directory lab on Proxmox behind a pfSense firewall, with segmented VLANs, an operator VM, Sliver C2 tier, redirectors, and an ELK SIEM for defensive monitoring.

Tool	pho5nix/Red-Team-GOAD-Lab-Proxmox — build guide for a segmented GOAD red teaming home lab on Proxmox with pfSense, C2 and redirectors
Category	Home lab build guide / lab infrastructure
Primary Use	Deploying an isolated GOAD Active Directory lab with realistic network segmentation, an operator tier (Kali), a Sliver C2 tier, redirector VMs and an ELK SIEM for purple-team training
Safe Use	Strictly for authorized, isolated, self-contained education and security training; the README explicitly instructs users to keep the lab offline and local, and to apply what is learned defensively
Telemetry Note	The lab includes its own GOAD-ELK SIEM (Elasticsearch/Kibana/Logstash) so every technique exercised inside the lab generates telemetry that defenders can study on the same infrastructure

pho5nix/Red-Team-GOAD-Lab-Proxmox is not a tool in the traditional sense but a build guide — a documented architecture for standing up the well-known GOAD Game of Active Directory lab on a Proxmox hypervisor, fronted by a pfSense firewall and segmented into purpose-built VLANs. What distinguishes it from the average GOAD walkthrough is the network design: instead of a flat lab where everything can reach everything, the guide models an engagement-like topology with an operator segment, a redirector tier, the Active Directory estate itself, and a management segment for the analyst desktop. That segmentation is what turns a vulnerability playground into something closer to a training range for full attack-chain rehearsal against deliberately vulnerable, self-owned systems.

The README prescribes a strict build order: pfSense VLANs and firewall policy first, then the Operator and Redirector VMs, then the GOAD lab setup in Proxmox, and finally verification, snapshots and troubleshooting. This ordering is worth pausing on, because it reflects how experienced operators think: the network boundaries and egress controls exist before any offensive infrastructure is deployed. If the firewall policy is wrong, everything downstream behaves differently, so the guide front-loads the routing layer. The snapshot step at the end is equally telling — a lab you cannot reset cheaply is a lab you will stop experimenting in.

The segmentation scheme is laid out in a concrete table. VLAN 150 on 172.23.150.0/24 hosts the Kali operator workstation and an Ubuntu VM running the Sliver C2 framework. VLAN 160 on 10.60.160.0/24 carries the redirectors — separate Ubuntu VMs for HTTP/S traffic redirection and for DNS/SSH redirection. VLAN 56 on 192.168.56.0/24 is the vulnerable estate: the GOAD provisioning VM, five Windows VMs forming the AD lab, and the ELK SIEM. VLAN 100 on 10.10.100.0/24 is your own desktop or laptop. Addressing in 150, 160 and 100 comes from pfSense DHCP with reservations made after VM creation, while VLAN 56 is fully static via Terraform and Cloudbase-Init.

The AD estate itself is the standard GOAD cast, and the README documents it precisely. kingslanding (192.168.56.10) and winterfell (192.168.56.11) are Windows Server 2019 domain controllers for sevenkingdoms.local and north.sevenkingdoms.local, while meereen (192.168.56.12) is a Windows Server 2016 DC for essos.local. Two member servers round it out: castelblack (192.168.56.22) running MSSQL and IIS, and braavos (192.168.56.23) running MSSQL and ADCS. The deliberate version mix — 2016 and 2019 side by side, plus a certificate services role — is what gives GOAD its breadth of misconfiguration classes to study, from legacy protocol abuse to AD certificate template issues.

A design detail that reads as genuinely thoughtful: the GOAD hosts use the domain controllers themselves, specifically kingslanding at 192.168.56.10, as their DNS servers — a hard requirement for AD to function — while pfSense serves purely as their default gateway. Keeping name resolution inside the domain and routing on the firewall keeps the lab's behavior faithful to how a real AD forest works, rather than letting the lab firewall accidentally become the DNS authority and subtly changing how domain traffic behaves.

The resource budget is the part most home-lab builders will care about, and the README is unusually honest about it. The author's own host is a Beelink Mini PC GTi13 with an i9 CPU, 80 GB of RAM and a 1 TB SSD. The full build consumes roughly 28 vCPU, 48 GB of RAM and 620 GB of thin-provisioned disk across eleven VMs — the Kali operator at 4 vCPU/8 GB, the Sliver C2 box at 2/4 GB, each redirector at 2/2 GB, the provisioning host at 4/4 GB, each of the five Windows machines at 2/4 GB (DCs) or 2/2 GB, and the GOAD-ELK SIEM at 4 vCPU/8 GB. Against 80 GB of RAM that leaves about 30 GB of headroom for the Proxmox hypervisor itself and for snapshots, which is tighter than it sounds once you start snapshotting five domain controllers.

For operators with less hardware, the guide points at the GOAD-Light and MINILAB variants of the upstream project, which shrink the number of Windows VMs. This is the right escape hatch: the network architecture — segmentation, redirectors, SIEM — remains valid regardless of how many domain controllers you can afford to run, so the guide degrades gracefully on modest hosts rather than becoming irrelevant.

The inclusion of monitoring is what elevates this from a red-team-only build to a purple-team one. GOAD-ELK at 192.168.56.50 runs Elasticsearch, Kibana and Logstash on Ubuntu 26.04, pulling telemetry from the same Windows estate being attacked. Every technique exercised against GOAD — and GOAD is intentionally riddled with classic AD misconfigurations — produces Windows event logs, and the SIEM tier lets a defender sitting in VLAN 100 watch what those events actually look like. That dual perspective is the entire pedagogical value of the design: the same traffic is simultaneously the attacker's evidence of success and the defender's detection opportunity.

The redirector tier deserves its own comment, because it is the piece most guides skip. Two dedicated Ubuntu VMs in VLAN 160 — one for HTTP/HTTPS redirection, one for DNS and SSH — sit between the operator's infrastructure and the target estate, mirroring how real command-and-control traffic is laundered through disposable intermediary hosts so the C2 server never talks to a target directly. In a lab context this teaches network hygiene and, from the blue side, gives the ELK stack realistic-looking traffic patterns to baseline and alert on, all within the operator's own isolated hardware.

The README also carries a maintenance warning that reveals practical experience: command syntax for Packer, Terraform and GOAD itself should be checked against your freshly cloned GOAD repository at build time, because GOAD is actively maintained and variable file formats may change between releases. Anyone who has automated lab provisioning knows this failure mode — you follow a guide verbatim, the upstream Terraform variables have been renamed, and the build dies halfway through. Flagging it up front is a small but meaningful courtesy to readers.

The disclaimer at the end is explicit and worth quoting in substance: the lab is built strictly for education and authorized security training in an isolated, self-contained environment, the techniques it teaches are the same ones defenders need to understand to protect real systems, and users are told to keep it isolated, keep it local, and use what they learn to make things more secure. That framing matches how this guide should be consumed — everything in it, from the Sliver C2 tier to the redirectors, is scoped to deliberately vulnerable VMs the builder owns on private, non-routable subnets behind pfSense.

As a piece of documentation rather than code, pho5nix/Red-Team-GOAD-Lab-Proxmox earns its place in a professional's bookmarks through specificity: real subnets, real IP plans, per-VM resource budgets, a stated build order, and a monitoring tier that closes the loop. Anyone planning a GOAD deployment on Proxmox — whether for red-team skill maintenance, detection engineering practice against known-bad AD configurations, or interview preparation — gets a verified architecture to start from rather than a blank canvas, and the numbers are honest enough to plan hardware purchases around.

Official project repository for pho5nix/Red-Team-GOAD-Lab-Proxmox.

Download Tool

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.