Homelab Build — Part 12 — Putting It Together: Full Topology Recap

The Interconnected Architecture

Think of an enterprise homelab like a modern commercial airport terminal. The physical hypervisor acts as the terminal building, pfSense serves as security checkpoints directing passengers between distinct concourses, Active Directory acts as border control verifying passports and granting boarding passes, and your monitoring stack functions as air traffic control tracking every moving component on the tarmac.

Over the preceding eleven parts of this series, we stood up individual infrastructure roles from bare metal to telemetry. In isolation, standing up a domain controller, issuing a certificate template, or creating a Prometheus scrape target is straightforward. What defines production infrastructure, however, is the deterministic interplay between these subsystems across strict network boundaries.

When an engineer joins a workstation to the domain or executes an administrative command, they trigger a chain of cryptographic handshakes, DNS queries, firewall state evaluations, and time-stamped log entries. Understanding this end-to-end conversation is what transforms a fragile hobbyist rig into a resilient engineering testbed.

The Physical and Virtual Topology Map

The entire environment resides on a single physical compute node, pve01, running Proxmox VE. Physical segregation is replaced by 802.1Q tagged encapsulation on Linux bridges, allowing multiple discrete broadcast domains to pass across virtual switchports without leaking traffic.

+-----------------------------------------------------------------------------------------------+
| PHYSICAL HOST: pve01 (10.10.1.5) - Proxmox VE 8.x Hypervisor (ZFS Root + NVMe Pool)            |
+-----------------------------------------------------------------------------------------------+
       |                                       |
  [NIC eth0: WAN]                        [NIC eth1: Trunk]
       |                                       |
   vmbr0 (Bridged WAN)                    vmbr1 (VLAN-Aware Linux Bridge)
       |                                       |
+-------------------+                          |
| pfSense VM        |                          |
| WAN: DHCP (ISP)   |                          |
| LAN: 10.10.1.1/24 |                          |
| VLAN 10 Gateway   |==== 802.1Q Trunk ========+
| VLAN 20 Gateway   |                          |
| VLAN 99 Gateway   |                          |
+-------------------+                          |
       |                                       |
       +--------------------+------------------+-------------------+
       |                    |                                      |
+--------------+     +-------------------------------+     +---------------+
| VLAN 1 (Mgmt)|     | VLAN 10 (Servers)             |     | VLAN 20 (Clt) |
| 10.10.1.0/24 |     | 10.10.10.0/24                 |     | 10.10.20.0/24 |
+--------------+     +-------------------------------+     +---------------+
| pve01: .5    |     | dc01.lab.example.com: .10     |     | win11-01: .50 |
| pbs01: .15   |     |  - AD DS, DNS, CA (AD CS), NTP|     | (Workstation) |
| mon01: .30   |     | dc02.lab.example.com: .11     |     |               |
|  - Grafana   |     |  - Replica DC, DNS, GC        |     |               |
|  - VictoriaM |     | fs01.lab.example.com: .20     |     |               |
|  - Kuma      |     |  - SMB File Shares & DFS-N    |     |               |
+--------------+     +-------------------------------+     +---------------+

This layout enforces clear role boundaries. Management hosts reside on the native untagged LAN (VLAN 1), domain infrastructure services operate in VLAN 10, untrusted or general workstations run inside VLAN 20, and ephemeral isolated experiments reside in VLAN 99.

Network Segmentation and Firewall Matrix

A frequent failure mode in junior lab setups is flat routing—granting every VLAN unrestricted access to every other VLAN with an “allow any any” rule. While convenient, it conceals the operational realities of enterprise security boundaries. In our lab, pfSense evaluates traffic statefully on interface entry, enforcing least-privilege egress.

To enable domain members in VLAN 20 to authenticate, apply policy, and resolve internal names, pfSense maintains explicit firewall filter rules allowing only required Active Directory service ports from VLAN 20 into VLAN 10.

The Boot-to-Productive Lifecycle of a Domain Node

To appreciate how these distinct systems cooperate, examine what occurs when a newly provisioned Windows 11 workstation, win11-01, boots up on VLAN 20. The machine progresses through seven distinct operational phases across multiple network boundaries.

[win11-01: VLAN 20]      [pfSense: 10.10.20.1]    [dc01: 10.10.10.10]    [fs01: 10.10.10.20]    [mon01: 10.10.1.30]
        |                          |                      |                      |                      |
 1. DHCP Discover ────────────────▶|                      |                      |                      |
    DHCP Offer (IP, DNS=dc01) ◀────|                      |                      |                      |
        |                                                 |                      |                      |
 2. DNS SRV Query (_ldap._tcp.dc._msdcs) ────────────────▶|                      |                      |
    DNS Answer (dc01.lab.example.com) ◀───────────────────|                      |                      |
        |                                                 |                      |                      |
 3. Kerberos AS-REQ (Machine Pre-Auth) ──────────────────▶|                      |                      |
    Kerberos AS-REP (TGT + Machine Session Key) ◀─────────|                      |                      |
        |                                                 |                      |                      |
 4. NTP Request (UDP 123 - NT5DS sync) ──────────────────▶|                      |                      |
    NTP Response (Stratum 2 Clock Header) ◀───────────────|                      |                      |
        |                                                 |                      |                      |
 5. RPC Bind (Port 135) + AD CS Autoenrollment ──────────▶|                      |                      |
    Issued Machine Certificate ◀──────────────────────────|                      |                      |
        |                                                 |                      |                      |
 6. SMB Tree Connect (\\lab.example.com\sysvol) ─────────▶|                      |                      |
    GPO XML Files & Registry POL Downloaded ◀─────────────|                      |                      |
    DFS-N Referral Query (\\lab.example.com\dfs\data) ────▶|                      |                      |
    Referral Response: fs01 Target ◀──────────────────────|                      |                      |
    SMB Session Setup (TCP 445) ────────────────────────────────────────────────▶|                      |
    Drive Mapped to M:\Data ◀─────────────────────────────────────────────────────|                      |
        |                                                                                               |
 7. Scrape Request (WMI Exporter Port 9182) ◀───────────────────────────────────────────────────────────|
    CPU / RAM / Disk Metrics Returned ─────────────────────────────────────────────────────────────────▶|

Every single step in this progression relies on the preceding service functioning without defect:

1. Addressing & Gateway Assignment: The workstation broadcasts a DHCP Discover. pfSense replies with an IP in the 10.10.20.0/24 subnet, assigning its own interface (10.10.20.1) as the default gateway, but deliberately configuring the DNS server list to point exclusively at the Domain Controllers (10.10.10.10 and 10.10.10.11).

2. Locator Resolution: Before contacting Active Directory, Windows Netlogon queries DNS for SRV records matching _ldap._tcp.dc._msdcs.lab.example.com. Because DNS requests travel over port 53 across pfSense into VLAN 10, the DC resolves the query and returns its own priority and port.

3. Cryptographic Identity: The workstation constructs an AS-REQ packet encrypted with its cached computer account secret and transmits it to port 88 on dc01. The KDC verifies the machine credentials, returns an AS-REP containing a Ticket Granting Ticket (TGT), and validates the Netlogon secure channel.

4. Time Locking: The Windows Time service (w32tm) synchronises against the PDC emulator on dc01 over UDP 123. If the workstation clock drifts more than five minutes from the DC, Kerberos ticket decryption will immediately fail with KRB_AP_ERR_SKEW, halting all domain access.

5. Credential & Certificate Hygiene: The local Certificate Enrollment Client executes its background pulse. Communicating via RPC Endpoint Mapper (port 135) and dynamic RPC ports to the Enterprise Root CA on dc01, the client validates its computer account rights and enrolls a local machine certificate based on the Computer template established in Part 7.

6. Policy Enforcement & Storage Mounts: The Group Policy Client connects via SMB (port 445) to \\lab.example.com\sysvol to download GPOs. Among these policies is an item-level targeted drive mapping that queries DFS Namespaces, resolves the root referral, and maps network drive M: pointing to fs01.lab.example.com.

7. Continuous Telemetry: In the background, the WMI Exporter service listens on TCP 9182. Across the boundary from VLAN 1, mon01 queries this port every 15 seconds. If disk latency spikes, RAM exhausts, or a vital Windows service terminates, Prometheus flags an alert in Uptime Kuma and Grafana.

End-to-End Diagnostic Checklist

When standing up or auditing a segmented lab, verify each link in the communication chain using native, non-destructive diagnostic utilities. Run these commands from an administrative PowerShell prompt on a member workstation or server.

# 1. Verify Layer 4 TCP connectivity across pfSense to Active Directory core ports
Test-NetConnection -ComputerName dc01.lab.example.com -Port 389
Test-NetConnection -ComputerName dc01.lab.example.com -Port 88
Test-NetConnection -ComputerName dc01.lab.example.com -Port 135
Test-NetConnection -ComputerName dc01.lab.example.com -Port 445

# 2. Confirm Active Directory SRV locator records resolve correctly from DNS
Resolve-DnsName -Name _ldap._tcp.dc._msdcs.lab.example.com -Type SRV

# 3. Query the Netlogon DC locator to confirm which DC answered and which site we belong to
nltest /dsgetdc:lab.example.com

# 4. Verify secure channel integrity between the local computer and the domain controller
nltest /sc_query:lab.example.com

# 5. Check Windows Time synchronisation status, stratum level, and reference source
w32tm /query /status

# 6. Test Active Directory Certificate Services request interface reachability
certutil -ping

# 7. Query the Prometheus / VictoriaMetrics scraping endpoint on the management node
curl.exe -s http://10.10.1.30:8428/metrics | Select-String -Pattern "vm_uptime"

Healthy output across these tests demonstrates that pfSense routing rules, Active Directory authentication, DNS resolution, time synchronisation, PKI RPC listeners, and telemetry ingestion are operating as an integrated fabric.

Troubleshooting Inter-Subsystem Failures

When an issue surfaces in a segmented homelab, the root cause is rarely the component reporting the error. Use this diagnostic cheat sheet to trace symptoms back to their underlying boundary failure.

Final Thoughts

Building an enterprise homelab is fundamentally an exercise in systems thinking. Anyone can launch an automated script that deploys five virtual machines onto a flat subnet. However, taking the deliberate path—isolating trust tiers behind a stateful firewall, establishing authoritative time hierarchies, managing public key cryptography, automating GPOs, and wrapping the entire stack in real-time telemetry—builds authentic production competency.

When you encounter a real-world infrastructure failure in an enterprise datacentre, you will recognise the exact failure modes you engineered through in this lab. The mechanics of Kerberos tickets, RPC endpoint binding, and routing boundaries do not change between a homelab hypervisor and a thousand-node corporate infrastructure.