Last week I wrote about bringing an HP DL380 G7 back from fifteen months of cold storage. What I did not say was how close I came to bricking my own recovery.
The homelab had a bootstrap network I had set up in 2024 called 10.99.110.x. Nothing lived on it except the host's secondary IP and the NAS guest's second interface. When I set up VLAN 100 tagged as the new SERVERS network, I retired 10.99.110.x. Between the cutover and the moment pfSense started routing VLAN 100 correctly, my only management path to the box was that dying network. If pfSense had glitched mid-cutover, I would have been at the chassis with a keyboard.
That gap is what showed me what VLAN 200 MGMT is actually for. It also eventually pulled VLAN 300 DMZ out of me. Three VLANs today, each with a specific job.
SERVERS is where the work happens
VLAN 100 is 10.99.99.0/24. Every LXC, every VM, the PVE host's management IP. Pi-hole, Traefik VRRP VIP at .29, Nextcloud, GitLab, Authelia, Vaultwarden, the observability stack. It is the network that all my other posts talk about.
If SERVERS is broken, I need a way in that does not depend on SERVERS.
MGMT is where the recovery lives
VLAN 200 is 192.0.2.0/24. Very few things live on it. The host has a secondary IP at 192.0.2.5. iLO 3 lives at 192.0.2.3. My laptop drops on one of the MGMT-tagged ports on the switch and gets a MGMT address via DHCP.
Nothing on this VLAN has a default gateway. The whole point is that it does not route out. If SERVERS goes down, or if pfSense itself is broken, I can still direct-L2 to 192.0.2.5, log in over SSH, and see what happened.
iLO 3 also deserves its own segment for a different reason. Its firmware last shipped in December 2020. It only speaks TLS 1.0, only accepts DSA-1024 SSH keys, and answers IPMI/DCMI on UDP/623. That stack has no business being reachable from the wider LAN. On MGMT, only my laptop and the host itself can talk to it, and the pfSense rules between SERVERS and MGMT make sure nothing on SERVERS can escalate through it.
DMZ is where the internet gets in
VLAN 300 is 203.0.113.0/24. One IP is in use. 203.0.113.10 is my cloudflared LXC.
Cloudflared holds the outbound TLS session to Cloudflare's edge. Requests to cloud.iamkay.eu, ha.iamkay.eu, and a handful of other public routes flow inbound through that tunnel, hit cloudflared, and cloudflared forwards them to the Traefik VRRP VIP at 10.99.99.29 on port 443. The pfSense rule that allows this flow is one line:
src=203.0.113.10 -> dst=10.99.99.29 tcp/443
Nothing else can cross from DMZ to SERVERS. Cloudflared cannot SSH into anything, cannot hit Vaultwarden directly, cannot touch Nextcloud's data volume. It has exactly one job.
Enterprise DMZ patterns describe a /24 subnet full of load balancers, WAFs, and reverse proxies, all serving multiple internet-facing apps. That is the right model at that scale. At homelab scale, my entire DMZ is one process and one address. The rule set can be minimal because the surface is minimal.
The rules that tie it together
pfSense is the only device that can route between VLANs. The rules I care about most:
- SERVERS to MGMT is blocked with no exceptions. I verified this six different ways before trusting it.
- DMZ to SERVERS allows exactly
203.0.113.10 -> 10.99.99.29on tcp/443. Nothing else. - MGMT to anywhere is allowed, because MGMT is my hands. If someone is on MGMT they either have physical access to the switch or my laptop.
- SERVERS to the internet is allowed for outbound traffic: updates, DNS forwarding, mail relay, ACME challenges.
The switch itself is a TP-Link TL-SG108E v1. Static VLAN tagging, not 802.3ad. That kept me from doing LACP with pfSense, which is a whole other story I will get to. The host runs a single active-backup bond over two 1GbE NICs. VLAN tags terminate on vmbr0.100, vmbr0.200, and vmbr0.300 sub-interfaces.
Tradeoffs I know I have
Family devices are on the untagged VLAN 1 today. That is not a decision, it is an omission. When I move them to their own VLAN, the pfSense rules need to say family devices can reach cloud.iamkay.eu and nothing else on the homelab. That work is queued and not urgent. Right now the family is one household and I trust the trust boundary.
I do not have a full L3 switch. The TL-SG108E does static VLAN tagging fine, but everything routes through pfSense. If pfSense is a single point, MGMT is the fallback. If both are down at once, I am at the chassis.
What it comes back to
Each of the three VLANs is named for the thing it does. SERVERS holds the workloads. MGMT is how I reach them when SERVERS is down. DMZ is one process talking to the internet. The structure was not something I designed up front. It came out of asking, at every layer, what happens if this network dies.
The cold-storage recovery would have gone sideways if the box between my laptop and pfSense had died during the VLAN cutover. It did not, but that near-miss is what taught me the shape of MGMT. MGMT refuses to route anywhere. DMZ routes exactly one thing. Both segments exist to answer what happens when the primary path breaks.
Resources
- Post 1: The DL380 had been off for fifteen months - the recovery this one continues from.
- pfSense firewall aliases and rules docs - if you want to reproduce the rule shape.
