How to Configure Network Segmentation for Self-Hosted Services: A Layered Security Approach

Network segmentation isolates self-hosted workloads by combining VLANs, subnetting, firewall rules, Docker networks, and reverse proxies to limit the blast radius of security breaches.

The mikeroyal/Self-Hosting-Guide repository provides a comprehensive reference for building secure, isolated infrastructure at home. Proper network segmentation ensures that if one service is compromised, attackers cannot pivot to your entire LAN or sensitive data stores.

Why Network Segmentation Matters for Self-Hosting

Self-hosted environments typically mix critical infrastructure (NAS, backups, authentication) with internet-facing services (web apps, media servers, IoT hubs). Without segmentation, a vulnerability in a public-facing container grants direct access to your file server. By implementing multiple isolation layers—as detailed in the README.md—you create distinct security zones that enforce least-privilege access between services.

Six Layers of Network Segmentation

Physical and Virtual LANs (VLANs)

Virtual LANs (VLANs) create separate broadcast domains on the same physical switch or virtual switch. According to the guide, many smart devices already run on their own VLANs to prevent broadcast traffic from flooding the main network (README.md#L2550). You can configure VLANs on a managed switch or using a hypervisor’s virtual switch like Open vSwitch (README.md#L1235).

IP Subnetting

Subnetting divides larger IP ranges into smaller, routable blocks. The guide notes that smart devices "broadcast" only within their own subnet (README.md#L2550). Assign each VLAN a distinct /24 (or tighter) subnet—such as 192.168.10.0/24 for management and 192.168.20.0/24 for media servers—to create logical boundaries that routers can enforce.

Firewall Rules and Access Control

Firewalls control traffic between subnets. The guide references Network UPS Tools (NUT), iptables, and dedicated appliances like OPNsense or pfSense to enforce policies. Restrict cross-VLAN traffic to specific ports—for example, allowing only port 1883 between Home Assistant and an MQTT broker while blocking all other protocols.

Encrypted Overlay Networks (WireGuard, Tailscale, NetBird)

Overlay networks provide encrypted point-to-point links that can be further segmented. The guide lists WireGuard (README.md#L1197), Tailscale (README.md#L1197), and NetBird (README.md#L1195) as recommended solutions. You can create separate Tailnet ACLs or NetBird "projects" for each service group, ensuring remote access does not expose internal IPs directly.

Docker Container Network Isolation

Docker gives each container its own network namespace. The guide highlights Docker networking throughout (README.md#L30), including Docker Compose and Cilium. Define per-service networks with explicit subnets to prevent containers from communicating unless explicitly exposed via mapped ports or shared networks.

Zero-Trust Reverse Proxies

Centralize inbound traffic behind Traefik (README.md#L60), Caddy (README.md#L44), or Nginx-Proxy (README.md#L55). These zero-trust proxies terminate TLS and forward traffic based on hostnames, keeping backend services hidden from direct internet exposure and enforcing ACLs at the entry point.

Implementing Segmentation in the Self-Hosting Guide

Combine these layers to build a defense-in-depth architecture. Start by creating VLANs on your switch for logical groups—Management, Home Assistant, Media, and Databases. Assign unique subnets to each VLAN, then configure firewall rules to permit only necessary ports between zones.

Deploy services using Docker Compose with custom networks mapped to your VLAN subnets. The following example isolates Home Assistant and Mosquitto on separate networks while exposing them through a Traefik reverse proxy:

version: "3.9"

services:
  homeassistant:
    image: ghcr.io/home-assistant/home-assistant:stable
    restart: unless-stopped
    networks:
      ha_net:
        ipv4_address: 192.168.20.10

  mosquitto:
    image: eclipse-mosquitto:latest
    restart: unless-stopped
    networks:
      mqtt_net:
        ipv4_address: 192.168.30.10

  traefik:
    image: traefik:v2.10
    command:
      - "--providers.docker=true"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.myresolver.acme.tlschallenge=true"
      - "--certificatesresolvers.myresolver.acme.email=you@example.com"
      - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "letsencrypt:/letsencrypt"
    networks:
      ha_net: {}
      mqtt_net: {}
      proxy_net: {}

networks:
  ha_net:
    driver: bridge
    ipam:
      config:
        - subnet: 192.168.20.0/24
  mqtt_net:
    driver: bridge
    ipam:
      config:
        - subnet: 192.168.30.0/24
  proxy_net:
    driver: bridge
    ipam:
      config:
        - subnet: 192.168.40.0/24

Enforce host-level firewall rules to restrict inter-VLAN traffic. This iptables example allows only the Home Assistant subnet to reach the MQTT broker on port 1883:

# Allow HA VLAN to reach MQTT VLAN on 1883/tcp

iptables -A FORWARD -s 192.168.20.0/24 -d 192.168.30.0/24 -p tcp --dport 1883 -j ACCEPT

# Drop all other traffic between these VLANs

iptables -A FORWARD -s 192.168.20.0/24 -d 192.168.30.0/24 -j DROP

For remote access, deploy WireGuard on a dedicated "VPN" VLAN to prevent direct LAN access. This configuration restricts VPN clients to the Management subnet only:

[Interface]
PrivateKey = <server_private_key>
Address = 10.10.0.1/24
ListenPort = 51820

# Restrict VPN clients to Management VLAN only

PostUp = iptables -A FORWARD -i wg0 -s 10.10.0.0/24 -d 192.168.10.0/24 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -s 10.10.0.0/24 -d 192.168.10.0/24 -j ACCEPT

Summary

• VLANs and subnets create the physical and logical boundaries between service groups, as referenced in README.md#L2550.
• Firewall rules (iptables or OPNsense) enforce least-privilege access between VLANs, permitting only required ports.
• Docker networks isolate containers into distinct namespaces with explicit subnet assignments.
• Overlay networks like WireGuard and Tailscale (README.md#L1195-L1197) provide encrypted remote access without exposing internal LANs.
• Reverse proxies (Traefik, Caddy, Nginx-Proxy) centralize external access and terminate TLS at the network edge.

Frequently Asked Questions

What is the difference between a VLAN and a subnet?

A VLAN is a Layer 2 technology that creates separate broadcast domains on a switch, while a subnet is a Layer 3 logical division of an IP network. You typically assign one subnet per VLAN (e.g., VLAN 20 uses 192.168.20.0/24). The combination allows switches to segment traffic and routers to enforce policies between groups.

Can I implement network segmentation without a managed switch?

Yes. You can use Docker networks to isolate containers on a single host, iptables rules to restrict traffic between local subnets, and overlay networks like Tailscale or NetBird to create logical segments without hardware VLANs. However, physical VLANs provide stronger isolation for IoT devices and cannot be bypassed by misconfigured container settings.

How do I secure remote access to segmented networks?

Deploy WireGuard or Tailscale (README.md#L1197) on a dedicated VPN VLAN with strict firewall rules. Configure the VPN subnet (e.g., 10.10.0.0/24) to access only specific internal subnets—such as the Management VLAN (192.168.10.0/24)—while blocking access to sensitive ranges like NAS or backup networks. Always terminate remote connections at a reverse proxy rather than exposing internal IPs directly.

Should I use iptables or a dedicated firewall appliance like OPNsense?

Use iptables or nftables for simple, host-level rules on single servers. For multi-VLAN environments, a dedicated appliance like OPNsense or pfSense provides a centralized management interface, logging, and easier rule maintenance across your entire network. The guide mentions both approaches, with iptables suitable for Docker hosts and OPNsense ideal for router-level segmentation.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}