“When we build a network in a production environment, we always plan everything out so nothing breaks…” — words spoken by every Sysadmin moments before spinning up a server with no plan and spending the next three hours chasing down a routing issue. It can work out sometimes, but it’s rarely pretty. For my homelab, I wanted to actually do the planning upfront and avoid that particular headache down the road.
What are Service Zones?
Service zones are not a protocol or vendor feature. They are logical, domain-specific boundaries that group different types of services together. Below are some examples of the service zones in my homelab:
| Service Zone | Service Zone Domain | Example Services |
|---|---|---|
| Management | Core systems used to manage the Homelab. | OPNsense, Proxmox, switches |
| Storage | Systems that store files, databases, backups, or object data. | SeaweedFS, PostgreSQL, Proxmox Backup Server |
| Applications | Internal applications and web services | Forgejo, Kavita, Mealie, code-server |
| Monitoring | Tools used to watch, log, and monitor the environment | Uptime Kuma, Grafana, Graylog |
| Security | Tools used to enforce and audit security posture | Wazuh, CrowdSec, Suricata |
The service zones above are not the first form I came up with. I went back and forth between where to put storage VMs. I can see the argument for putting them under applications, which I originally had it under. I made the change to create its own because I realized that nearly everything would need to talk to those VMs, so it made more sense to separate them out from the other applications.
I had the same thoughts with the security and monitoring zones. They were originally grouped together, but I decided to split them for a few reasons:
- I decided to have more than one or two tools of each
- I wanted tighter security controls on the Security zone
- I liked the way it organized the network more
VLAN Creation
The subnet scheme follows a simple convention — the third octet always matches the VLAN ID, making it immediately readable in logs and firewall rules:
| VLAN ID | Service Zone | Subnet | Gateway |
|---|---|---|---|
| 10 | Management | 10.44.10.0/24 | 10.44.10.1 |
| 20 | Storage | 10.44.20.0/24 | 10.44.20.1 |
| 30 | Applications | 10.44.30.0/24 | 10.44.30.1 |
| 40 | Monitoring | 10.44.40.0/24 | 10.44.40.1 |
| 50 | Security | 10.44.50.0/24 | 10.44.50.1 |
When you see 10.44.30.x in a packet capture, you already know it’s an Applications zone host. This speeds up troubleshooting considerably — you can target captures to the VLAN(s) where you know the problems are.
Inter-Zone Firewall Rules
The most important thing about VLANs is being able to control what data can cross the boundaries, and where it can go. It’s important to get the security rules in place early. I’m guilty of this myself. It’s easy to start with a flat network, but it is much harder to lock down access after everything is built. Start with a deny by default, then add rules that allow the minimum required access to make the services work.
Take Forgejo as an example. It lives in the Applications zone and needs access to PostgreSQL in the Storage zone. The rule looks like this:
| Rule | Source | Destination | Port | Action |
|---|---|---|---|---|
| Allow Forgejo → PostgreSQL | 10.44.30.x (Apps) | 10.44.20.x (Storage) | 5432 | Allow |
| Default deny | Any | Any | Any | Deny |
Forgejo gets exactly the access it needs — nothing more. If something else in the Applications zone tries to reach Storage without a rule, that traffic is dropped. This is least privilege applied at the network level, and it’s the kind of thing that feels like overkill right up until something goes wrong and you’re glad the blast radius was small.
A Starting Point
This has given my network a very solid foundation to build from. It is easier to document, easier to secure, and easier to change later
That said, my design will not stay static. As I add more services, I will need additional zones and VLANs, and that’s easier to do with a plan. I look forward to writing about those in the future