Every guide throughout this series involving genuinely public-facing exposure — Dynamic DNS, port forwarding, split-horizon DNS — has quietly assumed those exposed services sit somewhere reasonably isolated from your main network. A home lab DMZ makes that isolation explicit and deliberate, creating a dedicated network segment specifically for anything actually reachable from the public internet.
What Is a DMZ?
A DMZ (Demilitarized Zone), borrowed from traditional network security terminology, is a network segment positioned between your fully trusted internal network and the untrusted public internet, hosting specifically the services that truly need public accessibility while keeping everything else entirely separated from that exposure.
Why a Dedicated DMZ Beyond Standard VLANs
The VLAN segmentation already separates IoT, Trusted, and Servers segments from each other — but if any of those segments also contains a really internet-exposed service, a compromise of that specific service still starts from within a segment containing other, non-public services. A DMZ takes isolation further, specifically for anything actually reachable from the internet, keeping it separated even from your other internal server infrastructure.
What Belongs in a DMZ
- Reverse proxy handling external traffic – your Nginx Proxy Manager instance specifically handling public-facing requests (as opposed to purely internal reverse proxy use)
- Publicly accessible web services – a personal blog, a status page, or anything actually meant for public visitors
- VPN endpoints – the public-facing side of WireGuard or Tailscale’s exit points, where applicable
What Should Never Be in a DMZ
- Databases and backend storage – these should sit in your internal Servers VLAN, reachable only from the specific DMZ services that particularly need database access, never directly exposed themselves
- Management interfaces – Proxmox’s web UI, PBS, switch admin panels, and anything similar belong exclusively in your Management VLAN, never in the DMZ
- Personal devices and internal-only services – Vaultwarden, your internal dashboard, Gitea (unless deliberately made public) all belong in your Trusted or Servers segments
Setting Up a DMZ with pfSense/OPNsense
Using the router platform :
- Create a dedicated DMZ VLAN interface, separate from your existing Trusted, Servers, and IoT VLANs.
- Define firewall rules specifically restricting the DMZ’s outbound access to your internal network — DMZ devices generally shouldn’t be able to initiate connections into your Trusted or Servers VLANs at all, only respond to legitimate return traffic.
- Allow only the specific inbound ports truly needed (80/443 for a web-facing reverse proxy, for instance) from the internet into the DMZ.
- Define narrow, specific rules for any legitimate DMZ-to-internal communication needs (a reverse proxy needing to reach an internal backend service, for instance), rather than broad access.
Port Forwarding Only to the DMZ
Configure your router’s port forwarding rules (relevant to the Dynamic DNS guide covered earlier) to forward exclusively to devices within your DMZ segment, never directly to devices in your Trusted or Servers VLANs, ensuring the only really internet-reachable devices are the ones specifically designed and hardened for that exposure.
The Reverse Proxy as the DMZ’s Primary Resident
Nginx Proxy Manager () often serves as the DMZ’s central resident, receiving all inbound public traffic and routing it appropriately — critically, the actual backend services it proxies to can remain in your internal Servers VLAN, with only the reverse proxy itself sitting in the more exposed DMZ segment, significantly limiting what’s directly internet-reachable.
Hardening DMZ-Resident Services Extra Carefully
Anything living in a DMZ deserves the full weight of the security practices covered throughout this series applied without compromise — SSH hardening, UFW, Fail2Ban, regular Lynis audits, and prompt patching, since DMZ services represent your actually highest-exposure attack surface, the first thing an internet-based attacker would actually reach.
Monitoring DMZ Traffic Specifically
Given the DMZ’s elevated exposure, prioritize Suricata () monitoring specifically on this segment’s traffic, and consider a honeypot (also covered earlier) placed within or near the DMZ specifically to catch reconnaissance activity targeting your actual public-facing infrastructure.
Final Thoughts
Setting up a home lab DMZ takes the VLAN segmentation principles covered earlier in this series and applies them specifically and deliberately to your particularly internet-exposed services, ensuring a compromise of your public-facing reverse proxy or web service doesn’t provide a direct path into your internal Proxmox management interfaces, databases, or personal services. For any homelab exposing services to the public internet at all, a proper DMZ is the architectural foundation that makes doing so truly defensible rather than a significant, undifferentiated risk to your entire network.
Leave a Reply