Zero Trust Beyond Entra: VLAN Segmentation and Tailscale in Practice

The Problem

#

I ran a flat network for longer than I’d like to admit. One subnet. Everything on it. The NAS, the hypervisor, the IoT lights, some device I’d forgotten about. It worked fine – until I actually thought about what “worked fine” meant. A compromised smart bulb could scan the hypervisor. A guest’s phone had the same network access as my management workstation. The topology granted implicit trust to anything with a DHCP lease.

In enterprise security, “Zero Trust” usually means Conditional Access, MFA, device compliance – identity-layer controls through Entra ID and Intune. That’s correct but incomplete. Zero Trust is a network architecture principle, not just an identity framework. No implicit trust based on network location. Every connection authenticated and authorized, regardless of where it originates.

Most homelabs violate this completely. So do more enterprise networks than anyone wants to admit. This post describes the architecture I built to fix it – VLAN segmentation, Tailscale mesh networking, and tiered access control. The principles are the same ones you’d apply at enterprise scale, just with cheaper hardware and fewer change control meetings.

Solution Overview

#

The architecture uses six VLANs with distinct trust levels, Tailscale as the remote access and service mesh layer, and a tiered access model that controls which users can reach which services through which paths.

No VPN concentrator. No port forwarding. No exposed services on the public internet. Remote access is exclusively through Tailscale’s WireGuard-based mesh, with ACLs controlling which nodes can reach which services.

Prerequisites

#

• UniFi network gear (or any managed switch/router with VLAN support)
• Tailscale account with ACL configuration
• Proxmox VE (or any hypervisor for service hosting)
• Understanding of layer 3 routing and firewall rules

Implementation

#

VLAN Architecture

#

The network is segmented into six VLANs, each with a distinct purpose and trust level:

Each VLAN is a trust boundary enforced by UniFi firewall rules at the gateway (UniFi Cloud Gateway Ultra).

Firewall Rules: Explicit Deny, Explicit Allow

#

The firewall configuration follows the Zero Trust principle: deny by default, allow explicitly.

• Admin can reach all VLANs and all services. This is the management network – my workstation lives here.
• Family can reach the Core VLAN (where services run) and the internet. Family devices can access Jellyfin and Home Assistant, but cannot access the hypervisor, backup server, or security stack.
• IoT can reach the internet and Home Assistant (so automations work), but nothing else. A compromised smart bulb cannot scan the hypervisor or the NAS.
• Guest gets internet access only. No inter-VLAN routing. A guest’s phone cannot even ping the gateway of any other VLAN.
• Workers hosts compute workloads – containers, runners, anything that needs to do work but shouldn’t have broad network access. Controlled outbound only.
• Core has limited outbound – services can reach the internet for updates and API calls, but inter-service communication is controlled by service-level firewall rules.

This is the same model enterprise networks implement with 802.1Q trunking and next-gen firewalls. The hardware is different (a UniFi 8-port PoE switch instead of a Cisco Catalyst), but the architecture is identical.

Why VLANs Are Not Enough

#

VLANs solve the network segmentation problem: devices in different VLANs cannot communicate unless firewall rules explicitly allow it. But VLANs are location-based – they trust the physical (or wireless) network the device connects to.

This creates two gaps:

1. Remote access. When you’re not on the local network, VLANs don’t help. You need a secure overlay to reach services.
2. Identity binding. A VLAN trusts any device on it. If someone gets the Wi-Fi password for the management SSID, they’re on the management VLAN. There’s no identity verification at the network layer.

Tailscale fills both gaps.

Tailscale: Identity-Aware Overlay Network

#

Tailscale creates a WireGuard-based mesh network where every node authenticates with an identity (tied to an Entra ID account, Google account, or other IdP). Access is controlled by Tailscale ACLs, not network location.

The architecture exposes services through two Tailscale edge nodes:

• edge-services – accessible to family members, exposes Jellyfin and Home Assistant
• edge-admin – accessible only to admin accounts, exposes everything: Proxmox, security dashboards, all management interfaces

The ACL policy enforces this separation. Here’s the real policy (sanitized emails):

{
  "grants": [
    {
      "src": ["autogroup:owner"],
      "dst": ["*"],
      "ip":  ["*"]
    },
    {
      "src": ["group:family"],
      "dst": ["tag:jellyfin", "tag:homeassistant", "tag:edge-services"],
      "ip":  ["*"]
    },
    {
      "src": ["tag:monitor"],
      "dst": ["*"],
      "ip":  ["*"]
    }
  ],
  "groups": {
    "group:family": [
      "[email protected]",
      "[email protected]"
    ]
  },
  "tagOwners": {
    "tag:jellyfin":      ["autogroup:owner"],
    "tag:homeassistant": ["autogroup:owner"],
    "tag:edge-services": ["autogroup:owner"],
    "tag:edge-admin":    ["autogroup:owner"],
    "tag:monitor":       ["autogroup:owner"]
  }
}

The owner (autogroup:owner) gets full access to everything – that’s the admin tier. Family members can only reach Jellyfin, Home Assistant, and the edge-services node. The monitor tag allows Uptime Kuma to health-check all nodes. Everything else is denied by default.

A family member connecting via Tailscale from anywhere in the world sees exactly the same services they’d see on the local Family VLAN – and nothing more. An admin connecting via Tailscale gets full access to the management plane, regardless of physical location.

This is the critical Zero Trust property: access is determined by identity and policy, not by which network you’re connected to.

Tiered Access Control

#

The access model has four tiers:

Tier 1 – Admin (Admin VLAN + edge-admin):

• Full local access on the management VLAN
• Full Tailscale access (autogroup:owner → everything)
• No internet-facing access (nothing is exposed publicly)

Tier 2 – Family (Family VLAN + edge-services):

• Local access to Core VLAN services via Family SSID
• Tailscale access to Jellyfin, Home Assistant, and edge-services only
• Cannot access admin interfaces, hypervisor, or security tooling

Tier 3 – IoT (IoT VLAN):

• Internet + Home Assistant only
• No Tailscale access
• Cannot reach any other internal service or management interface

Tier 4 – Guest (Guest VLAN):

• Internet only
• No Tailscale access
• No access to any internal service

This maps directly to enterprise RBAC models. Replace “Admin” with “IT Operations,” “Family” with “Standard Users,” “IoT” with “unmanaged devices,” and “Guest” with “Contractors on guest Wi-Fi” – the architecture is the same.

How This Mirrors Enterprise Zero Trust

#

The enterprise version costs more and handles more users, but the architectural decisions are identical:

• Segment the network by trust level
• Authenticate every connection with identity
• Control access with policy, not network location
• Never expose management interfaces to untrusted networks
• Use an overlay/mesh for remote access instead of traditional VPN

DNS as a Trust Boundary

#

Internal DNS resolution runs through Technitium, a self-hosted DNS server on the Core VLAN. This provides:

• Internal resolution – services are addressable by hostname within the network
• DNS filtering – ad blocking and malicious domain blocking at the DNS layer
• Logging – DNS query logs feed into the security monitoring stack

From a Zero Trust perspective, DNS is a trust boundary that most architectures ignore. If a compromised device can resolve internal hostnames, it can enumerate your infrastructure. Running your own DNS gives you visibility into that resolution and the ability to restrict it per VLAN.

Security Considerations

#

• Tailscale’s control plane is hosted by Tailscale Inc. Your WireGuard keys are yours, but the coordination server is not. Tailscale attempts direct peer-to-peer connections first; when NAT traversal fails, traffic is relayed through Tailscale’s DERP servers – still encrypted end-to-end via WireGuard, so Tailscale cannot decrypt it, but the relay path means your traffic routes through their infrastructure. For most homelab and small business scenarios, this is an excellent trade-off.
• VLAN security depends on correct firewall rules. A misconfigured rule can silently allow cross-VLAN traffic. Test from each VLAN after any rule change:

# From a Guest device -- should fail
ping 192.168.1.1

# From a Family device -- should reach Core (services) VLAN
ping 192.168.6.1

# From a Family device -- should NOT reach Admin VLAN
ping 192.168.1.1

# From an IoT device -- should NOT reach Admin VLAN
ping 192.168.1.1

# Verify nothing is publicly exposed
nmap -p 1-65535 <your-public-IP>

• The edge nodes (edge-services, edge-admin) are high-value targets. They bridge the Tailscale mesh with the internal network. Harden them accordingly.
• Wi-Fi SSID/password is the weakest link in VLAN trust. 802.1X (RADIUS-based authentication) for the management SSID binds VLAN assignment to identity rather than just a Wi-Fi password – this largely closes the gap described in the “Why VLANs Are Not Enough” section. If your threat model includes physical proximity attacks, it’s worth implementing.

When to Use This / When Not To

#

Use this architecture if you run any self-hosted services that you care about securing. Even a basic “management VLAN + everything else” split is a massive improvement over a flat network.

Don’t use this as a template without adapting to your environment. The specific VLANs, trust levels, and Tailscale ACLs here reflect one person’s infrastructure and threat model. Your segmentation should reflect your services, your users, and your risk tolerance.

GitHub

#

The repo is private – it contains network-specific configs, VLAN assignments, and Tailscale ACLs I’m not publishing. Everything architectural is covered above. The VLAN structure and ACL patterns are designed to be adapted, not copied verbatim. Adjust the VLANs, trust tiers, and tag names to match your environment and threat model.