Building a secure, segmented home lab.

Build steps

1. Prepare the firmware.

   Enable Intel VT-x/VT-d or the equivalent virtualization and IOMMU options. Confirm the system boots from the installation media.

2. Install Proxmox VE.

   Select the target disk, set the administrative credentials, and assign a static management address that belongs to the current home subnet.

3. Open the management interface.

   From another computer, browse to https://<proxmox-address>:8006 and sign in.

4. Review the default bridge.

   Confirm vmbr0 is attached to the physical NIC and contains the host address and default gateway. The bridge allows VMs to use the physical connection.

5. Prepare storage and installation media.

   Upload the pfSense, Windows Server, and Ubuntu installation images. Reserve enough free storage for VM disks, snapshots, and future updates.

6. Create a named administrative account.

   After initial setup, add a named user and grant only the Proxmox path and role required for normal VM administration.

Build steps

1. Create internal Proxmox bridges.

   Add one bridge for each isolated segment. Internal-only bridges do not need a physical NIC attached.

2. Create the pfSense VM.

   Allocate approximately 2 vCPU, 2–4 GB RAM, and a small virtual disk. Mount the pfSense installer.

3. Add the network adapters.

   Attach one adapter to the upstream bridge for WAN and one adapter to each internal bridge for management, services, and jumpbox traffic.

4. Install pfSense and assign interfaces.

   Identify WAN and each internal adapter by MAC address, then assign clear interface names before setting addresses.

5. Set the gateway addresses.

   Give every internal interface a static address that will act as the default gateway for that segment.

6. Configure client addressing.

   Use DHCP for convenience or static addressing for infrastructure systems. Keep servers, the jumpbox, and management interfaces predictable.

7. Confirm outbound NAT.

   Automatic outbound NAT is sufficient for the initial lab. Confirm internal clients can reach the internet through the pfSense WAN interface.

Build steps

1. Create aliases.

   Add host aliases such as PROXMOX_HOST and network aliases such as HOME_NET. Names make policy easier to read and update.

2. Allow Proxmox administration first.

   On the jumpbox interface, allow the jumpbox host to reach PROXMOX_HOST on TCP 8006.

3. Allow the upstream router only if needed.

   If the jumpbox must open the router's local management page, allow only that host and TCP 443.

4. Block the rest of the home network.

   Place a block rule for HOME_NET below the narrow router allow. This prevents access to other personal devices.

5. Protect the management network.

   After each approved management-host allow, block the remainder of the management subnet.

6. Add broader internet access last.

   An allow-to-any rule can provide outbound internet access because protected internal destinations have already been matched and blocked above it.

7. Document every rule.

   Use descriptions that explain the source, destination, service, and reason. Avoid unexplained broad rules.

Build steps

1. Create the pfSense WireGuard tunnel.

   Generate the tunnel keys, choose a private tunnel subnet, and configure a UDP listen port.

2. Add the remote peer.

   Enter the client's public key and tunnel address. Keep AllowedIPs limited to the lab destinations the client needs.

3. Assign and enable the WireGuard interface.

   Interface assignment makes firewall rules and routing easier to understand and inspect.

4. Forward the UDP listener upstream.

   On the home router, forward the selected WireGuard UDP port to the pfSense WAN address.

5. Create the WireGuard firewall rule.

   Allow the VPN peer to reach the jumpbox on the required traffic. Do not begin with unrestricted access to every internal subnet.

6. Prepare the Windows jumpbox.

   Assign a predictable address, enable RDP with Network Level Authentication, and scope the Windows Firewall rule to the VPN source network.

7. Test from a genuinely external connection.

   Use a mobile hotspot or another network so the test traverses the public edge rather than staying inside the home LAN.

Test-NetConnection <jumpbox-address> -Port 3389

Build steps

1. Prepare the Windows Server VM.

   Assign a static address, set the pfSense interface as the gateway, rename the server clearly, and install current updates.

2. Point the server's DNS client to itself.

   After promotion, the domain controller should use its own address for DNS. Configure external DNS through server forwarders instead of the NIC.

3. Install AD DS and DNS.

   Add both roles, promote the server to a new forest, and choose the lab domain name.

4. Verify the DNS zone.

   Confirm it is stored in Active Directory and uses secure dynamic updates. The domain controller should have host and service records.

5. Force registration if records are missing.

   Flush and register DNS, restart Netlogon, and request domain-controller DNS registration.

ipconfig /flushdns
ipconfig /registerdns
net stop netlogon
net start netlogon
nltest /dsregdns

6. Test the AD service record.

   Query the LDAP SRV record and confirm it returns the domain controller and port 389.

7. Join a client.

   Point the client's DNS setting only to the domain controller, verify name resolution, and then join the domain.

8. Separate identities.

   Use a normal account for daily sign-in, a named administrative account for privileged work, and preserve the built-in administrator for controlled recovery use.

Build steps

1. Define configurable inputs.

   Accept DNS names, TCP targets, internet URLs, service names, certificate-warning days, timeouts, and an output directory.

2. Create one result format.

   Use PASS, WARN, FAIL, and INFO so every check can be displayed and exported consistently.

3. Wrap checks safely.

   Run each diagnostic in its own error handler so one failure does not stop the rest of the report.

4. Add network checks.

   Resolve DNS, connect to TCP host/port pairs with explicit timeouts, test internet URLs, and collect adapters and routes.

5. Add Windows checks.

   Collect WinHTTP and user proxy settings, firewall profiles, services, system time, and certificate information.

6. Write both report formats.

   Create a readable text summary and JSON output for later filtering, comparison, or automation.

7. Return meaningful exit codes.

   Use 0 when clean, 1 when warnings exist, and 2 when a check fails.

.\Invoke-WindowsNetworkDiagnostic.ps1

Build steps

1. Identify the public address.

   Record the current public IP without publishing it in project documentation.

2. Run the default TCP scan.

   Check common TCP services first and note whether results are open, closed, or filtered.

3. Check management ports explicitly.

   Confirm services such as SSH, HTTPS administration, Proxmox 8006, and RDP 3389 are not public.

4. Test the VPN UDP port separately.

   A normal Nmap scan does not answer the UDP question. Use a targeted UDP scan for the configured listener.

nmap <public-ip>
nmap -sU -p <wireguard-port> <public-ip>

5. Interpret UDP carefully.

   open|filtered is normal when the scanner receives no response. WireGuard intentionally ignores unauthenticated probe data.

6. Compare with the intended design.

   The desired result is no public TCP management service and only the planned UDP VPN path.

Build steps

1. Enable firmware wake support.

   Enable PCIe wake, disable ErP if it removes standby NIC power, and confirm the Ethernet LEDs remain active after a normal shutdown.

2. Confirm Linux NIC support.

   Use ethtool on the physical interface and confirm it supports and enables magic-packet wake with Wake-on: g.

3. Build the packet.

   Use the physical Ethernet MAC, not the bridge MAC, and the subnet broadcast address.

$mac = "AA:BB:CC:DD:EE:FF"
$macBytes = $mac -split '[:-]' | ForEach-Object {
    [Convert]::ToByte($_, 16)
}
$packet = [byte[]](,0xFF * 6 + ($macBytes * 16))
$udp = New-Object System.Net.Sockets.UdpClient
$udp.EnableBroadcast = $true
$udp.Connect("192.168.1.255", 9)
[void]$udp.Send($packet, $packet.Length)
$udp.Close()

4. Capture before shutting down.

   While Proxmox is running, listen for the packet on every interface and send it from Windows.

sudo tcpdump -ni any udp port 9

5. Confirm the full path.

   A 102-byte packet should appear on the physical NIC and the Linux bridge with the broadcast destination.

6. Test after a normal shutdown.

   If the packet was proven but the host still does not wake, investigate shutdown-state NIC power, firmware, and driver behavior rather than rewriting the sender.