The Zero-Trust Access Tier: Twingate, Guacamole, and a Hardened Jumpbox
August 19, 2026
The lab should be reachable by me from anywhere, and by no one else from anywhere. Those two requirements sound compatible until you try to satisfy the first one the lazy way, with a forwarded port or a VPN endpoint painted on the public internet, and quietly break the second. This tier is how I get in without opening the front door: Twingate for the network, Guacamole for the screen, a jumpbox to keep the blast radius small.
The threat model: nothing listens inbound
Almost every home-lab compromise story starts the same way, with something listening on the public internet: an exposed RDP, an old SSH, a VPN appliance with a CVE. So the design rule for this tier is blunt. No inbound ports. The lab reaches out to a broker; the outside world never reaches in. You can't exploit a port that was never opened.
Architecture
Twingate cloud broker
╱ (identity + policy) ╲
client ──────╱ ╲────── outbound only
(Twingate app) │ │ ┌─────────────────────┐
│ └──▶│ Twingate connector │
│ │ (outbound only) │
▼ └──────────┬──────────┘
identity-scoped │ internal VLAN
resource access ▼
┌───────────────────────────┐
│ Apache Guacamole (HTML5) │
│ RDP · SSH · VNC in browser│
└─────────────┬─────────────┘
▼
┌───────────────────────────┐
│ Hardened Windows jumpbox │
│ watched entry point │
└─────────────┬─────────────┘
▼
segmented lab targets
reverse proxy ── TLS termination + auth for internal web UIs
RustDesk ── self-hosted screen control relayTwingate: outbound-only network access
Twingate replaces the VPN. Instead of publishing an endpoint, a connector inside the lab makes an outbound connection to Twingate's broker and waits. When I authenticate from my client, the broker brokers a session to a specific resource (not the whole network, a specific resource) based on my identity. The connector is a tiny container that costs almost nothing to run and opens exactly zero ports. The whole model depends on scoping those resources narrowly (this host, this port, this person) rather than defining one broad resource that turns the connector back into a flat VPN with extra steps, so a stolen session reaches one thing, not the lab.
Apache Guacamole: the screen, in a browser
Once I am on the network, I still need to see machines. Guacamole is a clientless remote-desktop gateway. It speaks RDP, SSH, and VNC on the back end and renders them as HTML5 in the browser on the front end. No native RDP client on my laptop, and, the real win, no RDP port exposed to me at all. I talk HTTPS to Guacamole, and its proxy daemon talks RDP to the target from inside the segment.
# Guacamole has three moving parts. Keep the sharp one internal:
# guacamole (web app) ──HTTP──▶ behind reverse proxy + auth [reachable by me]
# guacd (proxy daemon) ──RDP/SSH/VNC──▶ targets [internal only]
# database (auth/conns) ────────────────────────────────────── [internal only]The trap to avoid is locking down your own access and then leaving 3389 on the targets reachable from anywhere the proxy daemon can route. RDP stays reachable only from the proxy daemon's segment, the web app sits behind the reverse proxy and authentication, and the proxy daemon itself is never published.
The jumpbox: one door, small blast radius
Management traffic doesn't go straight from Guacamole to every target. It hops through a hardened Windows jumpbox: one box to patch aggressively, one box to watch closely, one chokepoint where lateral movement has to pass through something I am actually paying attention to. If an endpoint is going to be the compromised foothold, I would rather it be the one built to be watched.
RustDesk and the reverse proxy: the supporting cast
RustDesk is a self-hosted screen-control relay, the same "don't send my screen through a vendor's cloud" logic as everything else here, for the cases where I want direct remote control rather than a Guacamole session.
The reverse proxy is the one TLS terminator and auth layer in front of the internal web UIs, so each service doesn't roll its own certificate and login. One place to manage certs, one place to enforce a login wall. That same concentration makes it a single point of failure, so it is monitored like the critical dependency it is (the observability tier watches it) and its config lives in version control, where a bad change is a git revert rather than an archaeology dig.
Why it's designed this way
- Outbound-only, by rule. The connector dials out; nothing listens in. This single decision removes the entire category of exposed-port compromises.
- Identity, not network location. Being "on the network" grants nothing. Access is brokered per-resource, per-person, so a foothold is not a skeleton key.
- One screen gateway. Guacamole means no exposed RDP and no native clients, just an authenticated browser session.
- A watched chokepoint. Concentrating management access through a hardened, closely watched host shrinks the blast radius of any single compromise.
Taken together, this tier is the network-edge layer of a defense-in-depth model: identity-brokered, outbound-only access in front, so reaching any internal service means getting through the broker and the jumpbox first, not stumbling onto an open port.
What's next
- MFA on every path, enforced at Twingate and at the Guacamole login, not just one of them.
- Session recording on Guacamole so remote sessions are auditable after the fact, not just authorized before it.
- Policy from inventory, generating Twingate per-resource policies from the lab's own guest inventory instead of maintaining them by hand.