Operational Infrastructure
A self-built network infrastructure spanning a segmented home network in the UK, a Raspberry Pi server in Romania, and a DigitalOcean cloud gateway layer. Built around defence-in-depth: dedicated firewall hardware, five isolated VLAN segments, an encrypted WireGuard tunnel as the sole path to private services, and no home WAN port forwarding for any public-facing service.
Self-hosted services run in production daily — Vaultwarden for credential management, a personal dashboard, and a client VPN for encrypted remote access. A dedicated DMZ segment is fully configured and prepared for future T-Pot honeypot deployment, which will feed real attacker data into LegionTrap TI once deployed.
A home lab that does nothing real is a hardware collection. This one handles production services, enforces actual security controls, and is built to generate security intelligence.
Motivation
Understanding network security in theory is straightforward. Operating it under real conditions is different. I wanted infrastructure that enforced actual decisions — not a topology drawn in a diagram, but one with hardware enforcing the rules, real services depending on it, and real consequences for getting it wrong.
The practical side was simple: I needed self-hosted password management and a VPN without depending on cloud vendors whose terms and data handling I can't control. Vaultwarden on hardware I own solves that.
Honeypot data is only meaningful if it comes from a real deployment. A VM on a local sandbox attracts nothing. A host sitting in a properly isolated DMZ on a residential IP attracts the kind of traffic that makes LegionTrap useful.
The home lab was built partly because LegionTrap needed a real data source. The DMZ design came first. The firewall rules followed. T-Pot deployment is the next step.
The result is infrastructure that is simultaneously a production environment (it handles real services I depend on daily) and a security research platform (once T-Pot is deployed, it will generate continuous attacker data). Neither role is a demo.
Verified architecture
The infrastructure spans three physical locations and uses two separate DigitalOcean droplets serving distinct roles. Verified end-to-end across four infrastructure batches in June 2026.
A dedicated DigitalOcean droplet that acts as the sole public entry point for private services. It receives HTTPS traffic for vault.crinvault.com and crinvault.com, terminates TLS with Caddy, and forwards all traffic to the Raspberry Pi through an encrypted WireGuard tunnel. No direct exposure of backend services. No Docker. No nginx.
A separate, independent DigitalOcean droplet serving all public-facing websites. Apache handles TLS and vhost routing. The ScribeSwift backend runs as a Uvicorn/FastAPI service bound to localhost only, proxied by Apache. MySQL binds to localhost only. No connection to cloudbridge-gw.
A Raspberry Pi 5 in Măldărești, Romania running private services in Docker containers. Accessible only through the WireGuard tunnel from cloudbridge-gw. No ports forwarded on the Romanian residential network. Backup process verified and corrected during the June 2026 infrastructure sprint.
A Netgate SG-3100 running pfSense Plus is the single routing and firewall authority for the UK home network. Five isolated VLAN segments with independent firewall rulesets. No port forwarding. The Synology RT2600ac operates in AP mode only — pfSense is the router.
Defence-in-depth
Six network segments with independent firewall rulesets. Inter-VLAN traffic is blocked by default. Each segment is granted only the access it needs to function. Verified against the live pfSense configuration in Batch 4.
Default untagged LAN segment. DHCP enabled.
Personal devices and NAS. Internet access permitted. Inter-VLAN communication blocked. Wireless access via Synology RT2600ac in AP mode.
Fully isolated segment prepared for future T-Pot honeypot deployment. Firewall rules are configured: RFC1918 unreachable, outbound HTTP/HTTPS and ICMP only. A static address is reserved internally for the planned T-Pot host. No active host currently deployed.
Isolates smart devices and IP cameras. Restricted to DNS and NTP only. Cannot reach any other VLAN. Short DHCP lease time limits rogue device persistence.
Isolated malware analysis environment. DHCP disabled; static IPs only. Internet access blocked by default. The only permitted cross-VLAN path is SCP to the planned future T-Pot host in VLAN20 for sample transfer.
Highest-isolation segment. No internet access. No inter-VLAN communication. Permits only pfSense GUI access and DNS resolution. Admin interfaces for the firewall and managed switch are reachable from this segment only.
Service routing
Private services and public-facing services use entirely separate paths. The two DigitalOcean droplets serve completely different roles and share no connection.
Path A — Private services via cloudbridge-gw:
Path B — Public websites via separate hosting droplet:
The separation between these two droplets is intentional and verified. CrinVault and Vaultwarden never route through the web/app hosting droplet. ScribeSwift and public websites never route through cloudbridge-gw.
This was confirmed end-to-end during the June 2026 verification sprint, resolving conflicting earlier documentation that implied a single droplet served both roles.
Design principles
Each segment is granted exactly the access it needs to function and nothing more. IoT devices get DNS and NTP. The management VLAN gets pfSense GUI access and DNS. The DMZ cannot reach internal networks. The lab cannot reach the internet by default. pfSense evaluates rules top-to-bottom; RFC1918 block rules are placed first on every interface.
No ports are forwarded on the UK home network WAN. No ports are forwarded on the Romanian residential network. All public-facing services route through the cloud gateway layer. Private services route exclusively through the WireGuard tunnel. The NAT port forward table on pfSense is empty — verified.
The WireGuard wg1 tunnel is the only route to Vaultwarden and CrinVault. Traffic enters cloudbridge-gw via HTTPS, Caddy terminates TLS, and the request is forwarded over the tunnel to the Pi. No path to the backend exists that bypasses this gateway. Verified by confirming the Pi has no resolvable public DNS records for these services.
A backup defect was discovered and resolved during the June 2026 verification sprint: the Vaultwarden backup script referenced a path that did not exist, producing silent empty archives. The script was corrected and the first valid backup was confirmed. This was found through systematic verification, not by noticing data loss.
Honest snapshot
Verified June 2026 — Batches 1–4 complete
Core infrastructure verified end-to-end. Architecture documentation corrected and confirmed. Backup defect resolved. T-Pot deployment pending.
Skills and practice
VLAN segmentation designed from first principles — not configured once and forgotten, but verified against the live firewall. Least-privilege per segment, RFC1918 block rules placed correctly, inter-VLAN communication matrix understood and enforced.
Production services with real dependencies: password management used daily, VPN providing daily connectivity, dashboard serving real use. The Raspberry Pi in Romania is managed entirely remotely — no local access available, so change discipline is not optional.
Two separate DigitalOcean droplets serving distinct roles. The separation between the private service gateway and the public hosting droplet was confirmed through systematic verification after earlier documentation incorrectly described a single combined droplet.
Systematic verification found a backup defect that had been silently producing empty archives. The defect was found and fixed before any data loss occurred. Backups are not assumed to be working — they are confirmed to be working.
All architecture documentation was produced through a structured AI-assisted verification process — comparing source documents against the live system, resolving conflicts, and producing a verified architecture summary marked clearly with what is confirmed, what is pending, and what cannot be claimed.
T-Pot is not deployed. The pipeline to LegionTrap is not active. This page says so. The design for both is complete and verified; the status is pending. Infrastructure documentation that overclaims is not documentation — it is a liability.
Process note
The Home Lab had no formal documentation before this portfolio effort. Notes existed, but they contained conflicting information — three different WireGuard tunnel IP ranges across documents, two mutually exclusive access architectures for Vaultwarden, and T-Pot described as operational in some sources and unconfirmed in others.
A structured verification sprint was run in June 2026 using the AI Development OS framework. Each infrastructure component was verified against the live system in separate batches. Conflicts were resolved, incorrect claims were corrected, and each confirmed fact was recorded with its verification source. The result is an architecture summary marked clearly with what is verified, what is pending, and what is deferred.
The sprint confirmed four systems in one day: cloudbridge-gw, the web/app hosting droplet, the Raspberry Pi, and the pfSense home network. It resolved the Vaultwarden access architecture conflict, fixed a backup defect, and established a record of verified facts for diagram creation.
Batch 5 — T-Pot — was deferred because T-Pot is not yet deployed. That is accurate documentation, not an oversight.
Architecture diagrams (DG-01 through DG-03) were generated from the verified summary using the same AI-assisted process, sanitised for public use, and reviewed for accuracy before publication.