Network Design in a Homelab: Segmentation, DNS and Service Access
Designing a homelab network with segmentation, DNS integration, and structured service access patterns for reliability and control.
This post covers how networking is designed within my homelab, including segmentation, DNS integration, and service access patterns.
As the number of services increased, network structure became critical for reliability, security, and predictability. A flat network quickly becomes difficult to manage, so a more structured approach was required.
Network Overview
The homelab runs on a private LAN, with services hosted on virtual machines and Docker containers.
Key components include:
- Proxmox host for virtualisation
- OpenMediaVault for storage
- Docker for service workloads
- Pi-hole for DNS
Each component has a defined role within the network.
Network Structure
The network is designed around:
- Static IP allocation for core services
- Predictable addressing for infrastructure components
- Separation between host, services, and clients
This reduces reliance on dynamic addressing and simplifies troubleshooting.
Service Access Flow
Access to services follows a consistent pattern:
Client Device
↓
Local DNS (Pi-hole)
↓
Reverse Proxy (Nginx Proxy Manager)
↓
Service (Docker / VM)
This standardises how services are accessed across the environment.
DNS Integration
DNS plays a central role in the network design.
Pi-hole provides:
- Local DNS resolution
- Domain mapping for services
- Centralised control of service access
Instead of using IP addresses, services are accessed via consistent hostnames.
Internal vs External Access
The system supports both internal and external access:
- Internal traffic resolves directly via local DNS
- External traffic is routed through Cloudflare and the reverse proxy
This ensures services are accessible while maintaining a controlled entry point.
Segmentation Approach
While the network operates within a single LAN, logical segmentation is applied through:
- Service separation (containers vs host vs storage)
- Controlled exposure via reverse proxy
- Limiting direct access to backend services
This reduces unnecessary communication between components.
Issues Encountered
Some challenges included:
- DNS inconsistencies between host and containers
- Services accessible externally but not internally
- Port conflicts and routing issues
- Understanding how Docker networking interacts with the LAN
Resolving these required aligning DNS, networking, and proxy configurations.
Key Learnings
- Networking design becomes critical as systems grow
- DNS and routing must be aligned
- Predictable addressing simplifies troubleshooting
- Segmentation improves both security and manageability
What’s Next
The next step is exploring backup strategies and data protection, including how important data is protected beyond RAID.