How to structure your HomeLab network?

Why structure matters

• A well-organized HomeLab network is more secure and makes later expansion easier.
• Beginners often struggle with core networking concepts like:
  • Network zone segmentation
  • Subnetting
  • VLANs
  • IP addressing
  • DHCP

Remote access (sponsor mention)

Christian recommends Twingate (ZTNA / “zero trust network access”) as a secure remote-access tool. He claims:

• Requests are verified and authorized before access is allowed.
• Works even across NAT devices and firewalls without needing:
  • Port forwarding
  • Firewall exceptions
• Integrates with various setups/tools (he mentions tutorials for):
  • SSH access
  • DevOps tools like Kubernetes/Terraform
• It’s free up to five users and 10 remote networks.

Network documentation + topology planning

• First step: outline network topology and write it down.
• Tool: Xcawiraw (likely “excalidraw”) for creating diagrams.
  • Mentions a free browser tier and local storage.

He also documents important IP details, including:

• Critical static infrastructure IPs, such as:
  • Proxmox cluster
  • Kubernetes cluster
  • Production servers
  • NAS
  • Home Assistant
• Many client devices rely on DHCP, so they may not have individually documented fixed IPs.

Segmentation using “network zones”

Christian uses logical network zones and enforces access control using firewall rules.

• WAN zone: “beyond the firewall” (includes router + public internet)
  • Example: 192.168.10.0/24
• LAN zone: normal private home devices (TVs, Xbox, phones, etc.)
  • Example: 10.10.0.0/16
• Production (server) zone: where lab servers live
  • Example: 10.20.0.0/16
• DMZ (planned / work-in-progress):
  • Purpose: isolate publicly accessible services (e.g., hosting a website) from internal production/testing.
  • He intends to use stricter policies for Internet-facing services.
  • He hasn’t fully implemented DMZ yet.

Subnetting explained (practical intuition)

• A /24 corresponds to 255.255.255.0, meaning:
  • first 24 bits = network
  • last 8 bits = host
• A /16 means:
  • first 16 bits = network
  • remaining bits = host space

His goal: choose subnet patterns so he can infer device purpose from the IP structure (e.g., clusters start with different prefixes).

Firewall enforcement using zone-based rules (OpenSense)

• He uses OpenSense as the main gateway/firewall controlling traffic between zones.
• Core idea:
  • Traffic between zones must pass through the firewall, so rules can strictly restrict access.

Rule examples he describes:

• Admin device (e.g., Mac Studio in LAN) allowed broad access (any port/destination).
• Regular devices (TVs, iPhones, etc.) restricted to only specific services.

Example service allowlists:

• LAN → DNS server on port 53
• LAN → Home Assistant on port 443

He also follows a default-deny style:

• Block LAN devices from reaching trunk/production/management networks unless explicitly allowed.

VLANs to avoid extra physical switches

Christian explains that VLANs (“virtual local area network”) allow splitting one physical switch into multiple isolated networks.

Why VLANs matter in a home lab:

• Without VLANs, you’d need separate physical switches per zone—too expensive and power-hungry.

VLAN trunking concept (tagged vs untagged)

• Access / untagged ports:
  • carry traffic for one VLAN as normal packets
• Tagged / trunk / transport port:
  • connects switch ↔ firewall and carries multiple VLANs using VLAN IDs

He describes VLAN configuration on both:

• The managed switch:
  • assign VLAN IDs
  • mark the uplink/trunk port
• The OpenSense firewall:
  • create VLAN interfaces with matching VLAN tags

Future plan using VLANs

• Extend VLAN separation to DMZ
• Connect Proxmox to DMZ using VLAN tagging so VMs can be placed into different VLANs/zones.

Proxmox + DMZ idea (planned)

• He wants Proxmox connectivity moved from the production VLAN to DMZ VLAN trunking.
• Goal:
  • Run a VM in DMZ (example: 10.30.x.x)
  • Enforce firewall policy so DMZ VMs can’t reach production, even if they share the same physical hosts.

DHCP and IP range management best practices

He discusses splitting addressing further with IP ranges to improve DHCP management and reduce conflicts.

DHCP basics

• Clients broadcast to request an IP.
• DHCP assigns:
  • an unused address
  • network parameters like gateway and DNS

Example: OpenSense DHCP server

• Enabled on the LAN interface
• DHCP pool limited to a memorable range (example style: 10.10.0.10–10.10.0.199)

Static IP conflict avoidance

• Keep static IPs in a different range than the DHCP pool.
• Note: conflicts can still occur in edge cases (e.g., an offline device with a static IP later comes back).

DHCP “static mappings” (reservations)

• Use MAC-based DHCP reservations to keep addresses consistent without fully manual static configuration.
• He notes you can recognize DHCP-assigned/static-mapped devices by IP positioning.

Mentioned guides/tutorials/promoted tools

• Referenced guides / videos (“other videos”):
  • excalidraw diagram tool tutorial
  • OpenSense firewall tutorial
• Sponsor:
  • Twingate tutorials covering setup and integrations (including DevOps tools)

Main speaker/source(s)

• Christian (primary speaker)
• Sponsor: Twingate (mentioned for ZTNA / remote access)