---
title: Network Segmentation for Homelabs
description: Practical network segmentation patterns for separating trust zones in a homelab
tags:
  - networking
  - security
  - homelab
category: networking
created: 2026-03-14
updated: 2026-03-14
---

# Network Segmentation for Homelabs

## Introduction

Network segmentation reduces blast radius by separating devices and services into smaller trust zones. In a homelab, this helps isolate management systems, user devices, public services, and less trusted endpoints such as IoT equipment.

## Purpose

Segmentation is useful for:

- Limiting lateral movement after a compromise
- Keeping management interfaces off general user networks
- Isolating noisy or untrusted devices
- Applying different routing, DNS, and firewall policies per zone

## Architecture Overview

A practical homelab usually benefits from separate L3 segments or VLANs for at least the following areas:

- Management: hypervisors, switches, storage admin interfaces
- Servers: application VMs, container hosts, databases
- Clients: laptops, desktops, mobile devices
- IoT: cameras, media devices, printers, controllers
- Guest: devices that should only reach the internet
- Storage or backup: optional dedicated replication path

Example layout:

```text
VLAN 10  Management   192.168.10.0/24
VLAN 20  Servers      192.168.20.0/24
VLAN 30  Clients      192.168.30.0/24
VLAN 40  IoT          192.168.40.0/24
VLAN 50  Guest        192.168.50.0/24
```

Traffic should pass through a firewall or router between zones instead of being bridged freely.

## Design Guidelines

### Segment by trust and function

Start with simple boundaries:

- High trust: management, backup, secrets infrastructure
- Medium trust: internal application servers
- Lower trust: personal devices, guest devices, consumer IoT

### Route between zones with policy

Use inter-VLAN routing with explicit firewall rules. Default deny between segments is easier to reason about than a flat network with ad hoc exceptions.

### Use DNS intentionally

- Give internal services stable names
- Avoid exposing management DNS records to guest or IoT segments
- Consider split DNS for remote access through Tailscale or another VPN

### Minimize overlap

Use clean RFC 1918 address plans and document them. Overlapping subnets complicate VPN routing, container networking, and future site expansion.

## Configuration Example

Example policy intent for a firewall:

```text
Allow Clients -> Servers : TCP 80,443
Allow Management -> Servers : any
Allow Servers -> Storage : TCP 2049,445,3260 as needed
Deny IoT -> Management : any
Deny Guest -> Internal RFC1918 ranges : any
```

Example address planning notes:

```text
192.168.10.0/24  Management
192.168.20.0/24  Server workloads
192.168.30.0/24  User devices
192.168.40.0/24  IoT
192.168.50.0/24  Guest
fd00:10::/64     IPv6 management ULA
```

## Troubleshooting Tips

### Service works from one VLAN but not another

- Check the inter-VLAN firewall rule order
- Confirm DNS resolves to the intended internal address
- Verify the destination service is listening on the right interface

### VPN users can reach too much

- Review ACLs or firewall policy for routed VPN traffic
- Publish only the required subnets through subnet routers
- Avoid combining management and user services in the same routed segment

### Broadcast-dependent services break across segments

- Use unicast DNS or service discovery where possible
- For mDNS-dependent workflows, consider a reflector only where justified
- Do not flatten the network just to support one legacy discovery method

## Best Practices

- Keep management on its own segment from the beginning
- Treat IoT and guest networks as untrusted
- Document every VLAN, subnet, DHCP scope, and routing rule
- Prefer L3 policy enforcement over broad L2 access
- Revisit segmentation when new services expose public endpoints or remote admin paths

## References

- [RFC 1918: Address Allocation for Private Internets](https://www.rfc-editor.org/rfc/rfc1918)
- [RFC 4193: Unique Local IPv6 Unicast Addresses](https://www.rfc-editor.org/rfc/rfc4193)
- [Tailscale: Subnet routers](https://tailscale.com/kb/1019/subnets)
- [Tailscale: Access controls](https://tailscale.com/kb/1018/acls)