How the lab is connected, secured, and made accessible from anywhere.
There are two separate paths for remote access, each optimised for a different use case.
A cloud VPS acts as the public-facing entry point for all externally accessible services. An always-on outbound tunnel connects the home network to the VPS, initiated from the home side. Incoming HTTPS traffic on the VPS is handled by a reverse proxy, which forwards requests through the tunnel to the appropriate service on the LAN. From the internet's perspective, everything terminates at the VPS.
Personal devices connect directly to the home LAN via an encrypted device mesh. The mesh provides direct access to the home network for authorised devices without going through the public reverse proxy. This path is used for admin access, SSH, and anything that should never be publicly reachable.
The LAN is firewalled and routed by a BSD-based firewall VM running on host0. It is the only machine with physical network interfaces, so all traffic in and out of the lab passes through it.
Handles all routing, NAT, and DNS for the home network. Default deny on inbound, with explicit rules for the tunnel and any inter-VLAN traffic. The tunnel is initiated outbound so no inbound firewall exceptions are needed on the home side at all.
Firewall with a minimal allowlist: only the ports needed for HTTPS, the tunnel, and device mesh coordination. SSH is key-only with password authentication disabled and root login restricted. All other ports are denied by default.
Key-based authentication only across all hosts. Password authentication is disabled on the VPS and all Linux VMs. SSH access to internal hosts is restricted to the device mesh, not reachable through the public VPS.
The tunnel between the home network and the VPS is the backbone of the whole setup. It was chosen for its simplicity and the fact that it can be initiated outbound, which is essential when the home connection has no inbound port forwarding available.
The firewall VM on host0 maintains a persistent outbound connection to the VPS. The VPS treats the home network as a routable subnet and forwards traffic into it through the tunnel. The connection recovers automatically if the home IP changes or the connection drops.
The device mesh provides the personal access layer. It sits alongside the tunnel rather than replacing it: the tunnel handles public service traffic, while the mesh handles direct device-to-LAN access.
The mesh provides direct access to the home network for authorised devices, with an encrypted connection that does not route through the public reverse proxy. Peer discovery and NAT traversal are handled automatically.
The mesh currently includes the VPS, the home network services host, the network management VM, and a separate remote node. All nodes run the same current stable release.
All public traffic enters through the reverse proxy on the VPS. It terminates TLS, applies security headers, and routes requests to the right service on the LAN through the tunnel. A self-hosted identity provider sits behind it and provides SSO for the entire service stack.
The reverse proxy runs on the VPS and handles all inbound HTTPS. It manages TLS certificates automatically, applies a consistent set of security headers across all domains, and includes CalDAV and CardDAV redirects so native calendar and contacts clients work without any client-side configuration. A forward auth snippet is defined centrally so any service can be gated behind SSO with a single line.
A self-hosted identity provider runs on the services VM and handles authentication for the whole stack. Public services use OIDC. Services that do not support OIDC natively are covered by the reverse proxy's forward auth integration, so the login experience is consistent regardless of what each service supports internally.