Designing a Home Lab Network with Private IP Ranges
A well-designed home lab network avoids the conflicts that occur when your lab overlaps with your VPN or cloud infrastructure. Here's how to plan address space that stays out of your way.
A home lab is an excellent learning environment for networking, virtualisation, and cloud infrastructure. But nothing kills a learning session faster than IP address conflicts — your lab subnet overlaps with your corporate VPN, Docker takes over a range you need, or Kubernetes pods cannot reach the internet because of a routing collision. A few minutes of upfront planning prevents all of this.
Inventory Your Existing Address Space
Before allocating any lab addresses, document what is already in use:
- Your home router's LAN subnet (typically
192.168.0.0/24or192.168.1.0/24) - Your corporate VPN's subnet ranges (connect to VPN and run
route -norip route) - Any cloud VPCs you regularly connect to
- Docker default bridge (
172.17.0.0/16by default) - Any Kubernetes clusters and their pod/service CIDRs
Recommended Lab Addressing
Use a dedicated range from 10.0.0.0/8 for your lab — it is large enough to never run out and less commonly used by consumer equipment than 192.168.x.x. A practical allocation:
10.10.0.0/24— Physical hosts and hypervisor management interfaces10.10.10.0/24— Virtual machine LAN segment (your "lab internet")10.10.20.0/24— Isolated test network (for malware analysis or misconfigured services)10.10.30.0/24— Storage network10.20.0.0/16— Kubernetes pod CIDR10.30.0.0/16— Kubernetes service CIDR
Keep a gap between each segment so you can expand without renumbering. Use the CIDR calculator to verify that each block falls within your chosen supernet and does not overlap.
Avoiding Docker Conflicts
Reconfigure Docker's default bridge to use a subnet within your lab allocation — something like 10.10.50.0/24 — rather than the default 172.17.0.0/16. Set "bip": "10.10.50.1/24" in /etc/docker/daemon.json. Define custom Docker networks explicitly with docker network create --subnet for project networks.
Handling VPN Conflicts
Corporate VPNs often push routes for large swathes of private address space. If your VPN pushes a route for 10.0.0.0/8, any traffic to your lab 10.10.x.x will be tunnelled through the VPN — and fail to reach local machines. Solutions:
- Use split tunnelling (if your VPN client supports it) to only tunnel traffic that genuinely needs to reach corporate systems
- Choose a lab range your VPN does not cover — check the specific routes the VPN pushes
- Use a separate physical or VM-based router for the lab, isolated from the host's routing table
See the private IP ranges guide for a deeper look at RFC 1918 design principles.