Sample Blueprint: Security Homelab on Proxmox

This is the public proof-of-work sample for the Builder Blueprint ($149) tier. It shows the shape, depth, and decision-making customers receive before buying a custom Lab Blueprint.

It is a sample, not a plan for your hardware. Your real blueprint is built from your goals, budget, current gear, skill level, noise/power constraints, and risk tolerance.

What this sample proves

• The plan is specific: hardware, VLANs, guests, storage, backups, security, and build order.
• The plan is scoped to one clear goal: security skills that become interview stories.
• The plan is written so the buyer can execute it step by step.
• The plan includes judgment calls, not just checklists.

Lab Blueprint — Builder Tier ($149)

Customer: “Marcus C.” (anonymized with customer consent — intake Q23)
Delivered: Sample edition, published as public proof of work
Tier: Builder · Revision window: 21 days from delivery
Prepared and approved by: Charles Montago

1. Goals Summary

You’re a tier-1 helpdesk tech, two years in, studying for Security+ with a target of a SOC analyst role within 12–18 months. Your words: “In six months I want to talk about VLANs, log analysis, and detections in an interview because I’ve actually done them — not because I read about them.”

Primary goal (drives every trade-off below): a security-focused learning lab that produces interview-ready experience — segmentation, centralized logging, a SIEM with real detections, and safe attack/defend practice.

Secondary goals: Pi-hole for the household; a lightweight media server; Linux fundamentals along the way. These ride along where free; where they conflict with the security mission, the security mission wins.

Your constraints: $1,500 hard ceiling · lab lives in your apartment office (quiet hum acceptable, no server fans) · partner uses the internet daily and it must not break · skill level: comfortable Linux CLI, beginner networking, never used Proxmox · build-order preference: detailed, explain the why.

Assumptions made: your ISP router can be put in bridge mode; you’re comfortable replacing your household router as part of this build.

2. Hardware Plan

Disclosure: links below are affiliate links. We earn a commission if you buy through them; every pick here would be the pick at zero commission.

What you already own, and its job:

To buy (total: $1,428 — $72 under ceiling):

What we deliberately did not buy: a rack, 10GbE optics, a GPU, a NAS. None serve the primary goal this year; all appear in §10 when they might.

3. Proxmox Layout

Two independent Proxmox VE nodes — not clustered. A 2-node cluster needs a quorum device and adds failure modes you don’t need yet; clustering is a §10 milestone with a third node. Independence also makes the security boundary cleaner: pve-core (MS-01) runs your trusted services and SOC; pve-range (Dell) runs attackers and victims.

• pve-core (MS-01): Proxmox VE, ZFS mirror on 2× 1 TB NVMe (rpool), all four NICs wired (2.5GbE #1 = trunk to switch; 2.5GbE #2 = dedicated link to pve-range’s range trunk later; SFP+ dark for now)
• pve-range (Dell): Proxmox VE, single 1 TB SATA SSD ext4/LVM-thin (range guests are disposable; snapshots before every exercise, no mirror needed)
• Post-install on both: enterprise repo → no-subscription repo, microcode updates, zfs_arc_max capped at 16 GB on pve-core, fail2ban on the web UI, UI reachable only from the Management VLAN (§6)

4. VM / LXC Plan

pve-core (64 GB RAM — allocations below total 44 GB, leaving ARC + headroom):

pve-range (32 GB RAM — air-gapped by design, §6):

5. Storage Plan

• pve-core: rpool = ZFS mirror, 2× 1 TB NVMe → ~960 GB usable. Allocated above: ~460 GB thin-provisioned. Datasets: rpool/data (guests), rpool/media (Jellyfin library, quota 300 GB — media must never starve the SOC), rpool/iso. ARC capped 16 GB.
• pve-range: LVM-thin on 1 TB SATA. Range guests are cattle: golden snapshots after clean install, rollback after every exercise. This is a feature, not a compromise — reset discipline is range hygiene.
• Capacity math: Wazuh indices ~2–4 GB/day at your event volume with 90-day retention ≈ 180–360 GB worst case — fits with room; retention policy in §7 keeps it honest.
• Growth trigger: when rpool passes 70%, add the second pair of NVMe (MS-01 has the slot) or revisit retention — don’t let ZFS pass 80%.

6. Networking Plan

OPNsense box becomes your router (ISP router → bridge mode). Five VLANs on the managed switch:

Range isolation (the part most home “ranges” get wrong): pve-range guests live behind range-fw on physically separate NICs/bridge. Rules: Red/Victim segments have no route to VLANs 10–40 and no internet; exactly one pinhole exists — Wazuh agent/syslog traffic outbound from Victim segment to wazuh:1514/1515, initiated one-way. Kill switch: a single OPNsense rule (documented in the build order) drops the pinhole instantly. You get real telemetry from real attacks with zero exposure of the household.

DNS: Pi-hole for VLANs 20/30; lab/AD VLAN uses dc01 DNS forwarding to Pi-hole. Remote access: Tailscale only — zero inbound ports on the WAN.

7. Backup Plan

3-2-1, scaled honestly to a homelab:

Restore drill (non-negotiable, calendared): first Saturday monthly, restore one random guest from PBS to a temp VMID and boot it. An untested backup is a hypothesis. Your interview line: “I run monthly restore tests” — almost nobody can say it.

8. Security Recommendations

Matched to your exposure (no inbound ports, household stakes) and your goal (this section is curriculum):

1. No WAN exposure, period. Tailscale for remote access; revisit only in roadmap month 12+ with a reverse-proxy + IdP design.
2. Proxmox hardening: non-root admin user + 2FA on both nodes’ UIs; UI bound to Mgmt VLAN; fail2ban.
3. The Pi as tripwire: the Raspberry Pi sits on VLAN 20 running a syslog mirror + simple canary (e.g., an SSH honeypot like endlessh, alerting to your phone via ntfy). If the lab is ever compromised, the off-hypervisor Pi is your witness.
4. Sysmon everywhere Windows: SwiftOnSecurity baseline config on dc01, win11-client, vuln-win → Wazuh. This single step produces the telemetry that makes your detections real.
5. Detection cadence (the career engine): one detection per week from attack to alert: run the technique from Kali against the victim segment, find it in Wazuh, write/tune the rule, commit to detections repo with a short writeup. After 6 months you’ll have ~25 documented detections — that repo is a resume attachment.
6. Patch rhythm: household-facing services (VLAN 20) auto-update where safe; hypervisors monthly by hand (and snapshot first); range stays deliberately unpatched behind its isolation.
7. Secrets: Vaultwarden is on your §10 roadmap; until then, a local KeePassXC vault for lab credentials — never reuse household passwords in the lab.

9. Build Order

Each phase ends at a working, stoppable state. Detailed as requested — the why is in every step.

Phase 0 — Paper (evening): IP/VLAN plan printed (use §6 table), credentials vault created, this document skimmed end-to-end.
Phase 1 — Network spine (weekend 1): OPNsense box in, ISP router bridged, VLANs 10/20/30 live, household migrated to VLAN 30. Stop-state: family internet works and nothing else exists yet. Do not proceed until this has been stable for 48 h — the spouse-acceptance checkpoint is real.
Phase 2 — pve-core (weekend 2): RAM/NVMe into MS-01, Proxmox installed, ZFS mirror, post-install steps (§3), UI on Mgmt VLAN, UPS connected + NUT clean shutdown tested by pulling the plug on purpose.
Phase 3 — Household services (week 3, evenings): Pi-hole LXC → cut household DNS over; Jellyfin LXC with iGPU transcode; Tailscale subnet router; docker-host VM. Stop-state: the lab now earns its keep domestically — this buys you patience for the security build.
Phase 4 — SOC core (weekend 4): Wazuh VM on VLAN 50; enroll pve-core, OPNsense, Pi-hole, docker-host as agents/syslog sources; first dashboard; PBS LXC + first backup + first restore test.
Phase 5 — Windows lab (week 5–6): dc01 AD forest, win11-client joined, Sysmon both, logs flowing to Wazuh. Your first detection: detect your own failed-logon brute force with a Wazuh rule. Commit it.
Phase 6 — The range (weekend 7): Dell upgraded → pve-range; range-fw OPNsense; Red/Victim segments; golden snapshots; the one-way Wazuh pinhole; kill-switch rule tested before first attack. Then exercise one: Kali → Metasploitable, watch it land in Wazuh.
Phase 7 — Operate (ongoing): weekly detection cadence (§8.5), monthly restore drill (§7), monthly patch pass. This phase is the actual product of the lab — everything above was setup.

10. Expansion Roadmap (12 months)

Want this level of specificity for your own lab?

That is what a paid Lab Blueprint is for: your budget, your hardware, your goals, your constraints, and your build order.

Get your custom Lab Blueprint