eric/ericxliu-me
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

📚 Auto-publish: Add/update 1 blog posts
All checks were successful
Hugo Publish CI / build-and-deploy (push) Successful in 19s
Details

Browse Source 
Generated on: Mon Sep 22 07:27:14 UTC 2025
Source: md-personal repository
This commit is contained in:
Automated Publisher
2025-09-22 07:27:14 +00:00
parent 69c2890aad
commit 96e2f71ffd
1 changed files with 81 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

81
content/posts/unifi-vlan-migration-to-zone-based-architecture.md Normal file
View File

@@ -0,0 +1,81 @@
---
title: "UniFi VLAN Migration to Zone-Based Architecture"
date: 2025-09-22
draft: false
---
Embarking on a network migration to a properly segmented VLAN architecture is a rite of passage for any serious home lab or small business operator. The goal is clear: improve security and organization by separating traffic. However, the path from a flat network to a segmented one is often paved with subtle but critical configuration details that can lead to hours of frustrating troubleshooting.
This article documents that journey. It details the pitfalls encountered, the core networking concepts that were essential to understand, and the best practices that ultimately led to a stable, secure, and logical network design built on a zone-based firewall model.
### Lesson 1: Demystifying the Native VLAN
The most significant source of initial problems was a fundamental misunderstanding of the "Native VLAN" setting on a switch port.
**The Misconception:** It's easy to assume that the "Native Network" on a port should be set to the VLAN you want the connected device to be on. For example, if a switch should be on the "corp" network (VLAN 10), one might set its management VLAN to `corp` and the upstream switch port's Native Network to `corp` as well.
**The Reality:** The Native VLAN on a trunk port has a specific purpose: it determines which VLAN any **untagged** traffic belongs to. A trunk port is designed to carry traffic for multiple VLANs by adding a "tag" to each packet. The one exception is the traffic for the Native VLAN, which is sent *without* a tag.
This leads to a critical rule: **for a trunk link to function correctly, the Native VLAN must be the same on both ends of the connection.** When they mismatch, management traffic from devices like switches and access points gets lost, sending them offline.
### Lesson 2: The Power of a Dedicated Management VLAN
This realization about the Native VLAN led directly to the next critical architectural decision: isolating the network's control plane. The initial plan involved using VLAN 1 for a DMZ, but this is a significant security risk, as VLAN 1 is often the default "catch-all" network.
**The Best Practice:** The industry-standard solution is to create a dedicated **Management VLAN**. This network's sole purpose is to be the home for the management interfaces of your router, switches, and access points.
The final, secure architecture was as follows:
1. A new network, "Management" (e.g., VLAN 1, `192.168.1.0/24`), was created.
2. This network was assigned to its own "Management" firewall zone with highly restrictive rules.
3. All trunk ports connecting switches and access points were configured with "Management" as the **Native VLAN**.
4. All other user-facing VLANs (`corp`, `iot`, `dmz`) were configured as **Tagged VLANs** on these trunk ports.
This isolates the network's control plane from the data plane, vastly improving the security posture.
### Lesson 3: Mastering Inter-VLAN Communication
With traffic properly segmented at Layer 2, the next challenge was controlling communication at Layer 3. This is the job of the router and its firewall, and it presented a common challenge: providing DHCP to clients when the server resides in a different VLAN.
DHCP requests are broadcasts and are not passed between VLANs by a router. The solution is to use a **DHCP Relay**.
1. On the network configuration for a client VLAN (e.g., `corp`), the DHCP mode was changed from "Server" to "Relay".
2. The IP address of the actual DHCP server was specified.
This instructs the router to listen for DHCP broadcasts, catch them, and forward them as a unicast packet directly to the DHCP server. For this to work, the firewall must allow this traffic, and the DHCP server itself must be configured with a "scope" or pool of IP addresses for the client's subnet.
### The Final Architecture: A Zone-Based Firewall Model
The culmination of these lessons is a network architecture defined by clear, logical zones, each with a distinct purpose and trust level. This model simplifies firewall management and provides a robust security posture that is easy to understand at a glance.
#### Network Zones and Their Roles
The final configuration groups the individual VLANs into distinct zones, forming the foundation of the security policy.
* **Internal:** Contains the `corp` network. This is the most trusted zone for daily work.
* **DMZ:** Contains the `dns` and `prod` networks for semi-trusted, exposed services.
* **IoT:** Contains the `iot` network. This is a low-trust zone for smart devices.
* **Management:** Contains the `management` network. This is a highly privileged, isolated zone for network infrastructure.
#### The Security Policy Matrix
The true power of this model is realized in the firewall's zone matrix, which dictates the default traffic flow between each zone.
This matrix enforces the desired security policy with clear, high-level rules:
* **Complete IoT Isolation:** The `IoT` row shows that devices in this zone are blocked from initiating any communication with any other internal zone. Their only allowed path is out to the internet.
* **Protected Management Plane:** The `management` row and column are almost entirely red. The critical network infrastructure is blocked from initiating contact with any user-facing zone, and vice-versa, following the principle of least privilege.
* **Controlled DMZ Access:** The `DMZ` is prevented from initiating connections to the trusted `Internal` zone, preventing a compromised public-facing server from being used as a pivot point to attack internal devices.
#### Granular Intra-Zone Control
Beyond the high-level zone policies, the configuration also implements granular rules to control traffic *within* a single zone, providing defense-in-depth.
These rules explicitly define the communication paths between services. For instance, rules allow a specific device to access a Kubernetes load balancer while another rule allows general DNS access within the zone. This ensures that even within a semi-trusted zone, services can only communicate in expected and necessary ways, further reducing the potential attack surface.
By adhering to these principles, what began as a day of frustrating troubleshooting evolved into a robust, layered, and logically segmented network that balances simplicity with strong security practices.
***
### References
* [Troubleshooting UniFi Device Connectivity](https://help.ui.com/hc/en-us/articles/7258465146519-Troubleshooting-UniFi-Device-Connectivity)
* [Virtual Network (VLAN) Troubleshooting](https://help.ui.com/hc/en-us/articles/9592924981911-Virtual-Network-VLAN-Troubleshooting)