Context

Until recently, every machine in this homelab — from the public-facing portal to internal admin tools I'd never want exposed — sat on the same flat network. That's fine for a lab nobody else touches, but the moment I wanted to open the portal to outside visitors, that flatness became the actual risk: a single compromised public-facing service would have had a direct line to everything else.

The problem

Putting a firewall appliance in front of everything only solves part of the problem if every internal service still sits reachable behind that same firewall, on the same network segment. I wanted an architecture where compromising the one thing meant to be public (the portal) doesn't hand an attacker a path to anything else, even indirectly.

A tempting first plan was to move my whole reverse-proxy layer — which fronts close to ten internal services, not just the portal — into a more exposed network segment. I decided against it: that would have flattened the very separation I was trying to build, putting sensitive internal admin tools at the same trust level as the one thing meant to be public.

The solution

Three network zones: the exposed one facing the internet, a narrow buffer zone (a "DMZ", historically short for demilitarized zone) holding only what has to be reachable from outside, and an internal zone holding everything else. The reverse proxy that fronts almost every internal tool stays untouched, on the internal zone. A new, minimal reverse-proxy instance was created just for the DMZ, configured to know about exactly one thing: the public portal.

The firewall rule set is deliberately narrow: the exposed zone may only reach the buffer zone, and only on the one port the portal needs; the buffer zone may reach one specific internal address on one specific port; nothing may ever initiate a connection from the internal zone back out into the buffer zone. An intrusion detection layer and a VPN-only path for administrative access are part of the same design, rolled out in stages rather than all at once.

Rolling it out without a big bang

The riskiest step — moving the cluster's own nodes into the internal zone behind the firewall — was staged deliberately, one node at a time, specifically so a failure would only ever affect a fraction of the service rather than all of it. Good thing it was: the very first attempt hit a networking assumption that didn't hold once two physical hosts needed to talk to each other across this new segmentation, and had to be rolled back entirely, cleanly, without half-finished state. That hardware has since arrived; the work resumes at the next safe checkpoint, one node at a time, as before.

What I'd tell someone starting this

Segment for a reason, not for the diagram. The three-zone shape only earns its complexity because exactly one service needs to be public — if nothing did, I wouldn't bother. And stage every migration so a mistake costs you one node, not the whole cluster.