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 Link to heading

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 Link to heading

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 Link to heading

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 Link to heading

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 Link to heading

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. S3 File

The Security Policy Matrix Link to heading

The true power of this model is realized in the firewall’s zone matrix, which dictates the default traffic flow between each zone. S3 File

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 Link to heading

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 Link to heading