132 lines
4.2 KiB
Markdown
132 lines
4.2 KiB
Markdown
---
|
|
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)
|