What Is Network Segmentation? (VLAN Rules)
Network segmentation divides a switched network into separate Layer 2 broadcast domains, usually by assigning devices to VLANs. Traffic between VLANs must pass through a router, firewall, or Layer 3 switch, where rules can allow required connections and block others. VLANs organize traffic; they do not create secure boundaries unless routing policy enforces separation.
A common durability myth is that a network stays isolated once devices have different VLAN IDs. It does not. A permissive routing rule, a misassigned port, or an overly broad trunk can undo that separation. I treat VLANs as a way to organize traffic, then verify the controls that decide what traffic may cross between them.
What Network Segmentation and VLANs Mean
Network segmentation separates devices into groups so that traffic can be managed between them. A VLAN, or virtual local area network, creates a separate Layer 2 broadcast domain on a switched network. To control communication between those groups, route traffic through a device that can enforce policy.
A broadcast domain is the set of devices that receive a local broadcast, such as certain address-discovery messages. With VLANs, a switch can place different ports into different broadcast domains, even when those ports use the same physical switch. IEEE 802.1Q defines how VLAN information is carried in Ethernet frames.
A VLAN ID, or VID, is a 12-bit field. Standard VLAN IDs 1 through 4094 are usable; VID 0 is used for priority tagging, and VID 4095 is reserved. A VLAN tag adds four bytes to an Ethernet frame. Check the supported frame size of switches, network adapters, and other devices along the path rather than assuming every link handles tagged frames the same way.
The key distinction is between separation and access control. Devices in different VLANs do not communicate directly at Layer 2, but they may still communicate through a router or firewall. I plan policy at that routing boundary: allow the flows that are needed, and deny other flows.
Plan VLANs, Subnets, and Trust Boundaries
A VLAN plan maps each purpose to a VLAN ID, an IP subnet, and a gateway. This makes the design easier to review and troubleshoot. Before choosing numbers, inventory devices and required services, check for overlapping subnets, and decide which device will route between VLANs.
Start with roles, not a long list of arbitrary VLAN IDs. A small home or workshop network might separate trusted computers, smart devices, guest Wi-Fi, and network management. The right groups depend on what needs to communicate. A printer, for example, may need to accept print traffic from trusted computers, while guest devices should not gain access to management interfaces.
| Example purpose | VLAN ID | Example IPv4 subnet | Example policy |
|---|---|---|---|
| Trusted computers | 10 | 192.168.10.0/24 | Permit required internet and local services |
| Smart devices | 20 | 192.168.20.0/24 | Permit required DNS and internet access; restrict access to trusted devices |
| Guest Wi-Fi | 30 | 192.168.30.0/24 | Permit internet access; deny access to private local networks |
| Network management | 99 | 192.168.99.0/24 | Permit access only from approved administrator devices |
These are examples, not required settings. Use private IPv4 ranges specified by RFC 1918: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. Give each routed VLAN its own subnet and gateway. Confirm that the subnet does not overlap another local network or a remote network reached through a VPN.
For every VLAN, record its purpose, ID, subnet, gateway, DHCP scope or relay, DNS needs, and permitted traffic. List flows by source, destination, protocol, and port where practical. For example, a rule might allow a printer service from the trusted subnet to a printer’s address, rather than allowing all traffic between two whole VLANs.
I use this plan as a clearance check before making changes. It exposes missing requirements, such as a management computer that must reach a switch, or an IoT device that depends on a local controller. Keep the table current as devices and services change.
Check Trunks, Port Roles, and Management Access
A switch port’s role determines which VLAN traffic it carries. An access port usually places an endpoint in one VLAN. A trunk carries traffic for multiple VLANs between network devices, or between a switch and a device that supports tagged VLANs. Trunks need an explicit allowed-VLAN list and matching configuration at both ends.
For each link, identify the devices at both ends and whether it should be an access port or a trunk. Allow only the VLANs that link needs. A trunk transports VLAN traffic; it does not authorize communication between VLANs. That decision belongs to the routing or firewall policy.
Some trunks use a native VLAN for untagged traffic. Under the device’s configuration, untagged frames are associated with that VLAN. Match native-VLAN settings at both ends. Where supported, avoid carrying sensitive user traffic as untagged native traffic. Do not assume that a particular setting or label behaves identically across vendors.
Check management access before changing a switch, router, or wireless access point. Know which VLAN and path your management computer uses. If the new configuration removes that path, you may lose access before you can correct the error. Save a known-good configuration and arrange a tested way to recover, such as local console access or a documented rollback.
A useful inventory records:
- Switches, router or firewall, access points, and relevant device models
- Links between network devices and the VLANs each link needs
- Endpoint ports and their intended access VLAN
- Wireless SSIDs and their mapped VLANs
- Management addresses, routes, and approved administrator devices
This check catches simple but consequential errors, such as a user port left on the wrong VLAN or a trunk carrying a VLAN that was not part of the design.
Configure VLANs and Inter-VLAN Policy
Configuration has two parts: create the VLANs and assign ports, then set up the Layer 3 interfaces and rules that control traffic between them. Exact commands vary by vendor, so use the device’s documentation and confirm each setting in its running configuration before migrating production devices.
A careful sequence is:
- Create the VLANs on the switches that need to carry them.
- Set endpoint ports to the intended access VLAN.
- Configure each trunk at both ends and restrict its allowed VLANs.
- Create a gateway interface for each routed VLAN on the router, firewall, or Layer 3 switch.
- Configure DHCP scopes or relays, DNS access, and routes as needed.
- Apply inter-VLAN rules that permit required flows and deny other traffic.
- Move a small test group first, then expand after verification.
Use a distinct IP subnet and gateway for each routed VLAN. Ensure DHCP gives clients an address, subnet mask, gateway, and DNS settings appropriate to that VLAN. If a DHCP server is not in the client’s VLAN, check that a relay is configured where needed.
Write policy from least privilege. For instance, a guest VLAN may need DNS and internet access but not access to private local subnets. A smart-device VLAN may need a specific connection to a controller. Avoid a broad “allow any” rule between VLANs as a shortcut; it can defeat the purpose of segmentation.
Illustrative case: Suppose a homeowner separates trusted computers, smart devices, and guests. The switch places each group in its planned VLAN, while the router provides a gateway for each subnet. The homeowner then tests whether guests can reach the internet and whether they are blocked from the management subnet. This is a design example, not a claim about a particular installation. Its lesson is that the rule set, not the VLAN labels alone, determines the result.
Verify Isolation, Required Flows, and Recovery
Verification checks both sides of the policy: required connections must work, and prohibited connections must fail. Test from devices in each relevant VLAN after migration. A successful ping alone does not prove that all needed services work or that other traffic is blocked.
Begin with basic checks. Confirm that test devices receive an address in the correct subnet, use the intended gateway, and can resolve DNS names if required. Then test same-VLAN communication and each specifically permitted cross-VLAN service. Finally, test access that should be denied, including attempts to reach management interfaces from untrusted VLANs.
Useful checks depend on the equipment. Many managed switches provide commands such as show vlan, show interfaces trunk, and show mac address-table; syntax varies by vendor. On Linux, ip -d link can show link details and ip route can show routing information. Use the router or firewall’s logs and status pages to confirm whether a rule allowed or blocked a test flow.
| Test | Expected result | What a failure may indicate |
|---|---|---|
| Client address and gateway | Match the planned VLAN subnet | Wrong port assignment, DHCP scope, or relay |
| Required DNS lookup | Resolves using the intended DNS service | DNS rule, server, or client setting issue |
| Approved cross-VLAN service | Works only for the specified service | Missing route or overly narrow rule |
| Prohibited cross-VLAN access | Fails and is blocked by policy | Permissive rule, wrong VLAN, or alternate path |
| Trunk VLAN list | Contains only required VLANs | Misconfiguration or unintended VLAN exposure |
Check the native VLAN and allowed-VLAN lists at both ends of every trunk. Verify that a blocked test is not succeeding through another route, wireless network, or dual-connected device. Review logs where available, then document the results and update the network diagram.
Before a wider rollout, confirm a recovery path and keep a copy of the working configuration. Change a small test group first. If management access, DHCP, DNS, or required services fail, use the documented rollback rather than making rushed changes through an uncertain path.
Conclusion and VLAN Segmentation FAQ
A sound VLAN design starts with a clear device inventory and separate subnets for distinct groups. It then uses restricted trunks, correct port assignments, and explicit Layer 3 rules to control traffic. I verify allowed and denied paths before calling the separation complete, and keep a recovery plan ready for changes.
What does network segmentation do?
Network segmentation divides a network into groups so traffic can be organized and controlled. VLANs create separate Layer 2 broadcast domains; routing policy determines which groups can communicate.
Does a VLAN stop all communication with other VLANs?
No. A router, firewall, or Layer 3 switch may route traffic between VLANs. Rules on that device must control which traffic is allowed.
Are VLANs a security boundary by themselves?
No. A VLAN separates Layer 2 traffic, but a permissive routing rule, incorrect port assignment, or unintended trunk can undermine the intended isolation.
What is an 802.1Q tag?
It is a four-byte Ethernet frame addition that carries VLAN information. Check that network devices along the path support the tagged frame size being used.
What is the difference between an access port and a trunk?
An access port typically connects an endpoint to one VLAN. A trunk carries multiple VLANs between devices and should allow only the VLANs required on that link.
What is a native VLAN?
On a trunk configured with a native VLAN, untagged traffic is associated with that VLAN according to the device’s settings. Match the setting at both ends of the link.
Does every VLAN need its own subnet?
Every VLAN that is routed as a separate IP network should have its own subnet and gateway. Avoid overlapping subnets, including those used by VPNs or remote networks.
How can I test VLAN isolation?
Check device addressing, test required services, and attempt connections that policy should block. Review firewall or router logs; a failed ping alone is not a complete isolation test.
Should I allow every VLAN on every trunk?
No. Configure each trunk to carry only the VLANs it needs. This limits mistakes and reduces unintended paths, but does not replace inter-VLAN access rules.
What should I do before changing a live network?
Inventory devices and services, check VLAN and subnet support, save the working configuration, and confirm a tested recovery path. Migrate a small test group before expanding.
(This article was written by one of our staff writers, Garrett Vance. Visit our Meet the Team page.)
