Eleven VLANs and one flat network

An auditor asks whether the network is segmented. Somebody opens the switch configuration, counts eleven VLANs, and the answer is yes.

Both parties then move on, having established almost nothing about whether one part of the environment can reach another.

Two different things called a network

A VLAN is a broadcast domain. 802.1Q tagging separates traffic at layer 2, so a device in VLAN 30 does not see VLAN 40's broadcast and multicast traffic and cannot ARP directly for a host that sits there.

That is a real property and it is worth having. It helps contain broadcast traffic, gives the network a structure somebody can reason about, and prevents every endpoint from living in the same layer-2 failure domain.

What it does not do is decide whether a host in VLAN 30 can open a session to a host in VLAN 40. That decision happens when the traffic is routed between those networks. Creating another VLAN does not automatically mean that any restrictive policy exists between it and the VLANs already there.

The two get conflated because the diagram can look the same either way. Eleven boxes with lines between them can describe a strongly segmented environment or an environment in which almost everything can still reach everything else. The difference lives at the enforcement point.

Gateway placement chooses the enforcement point

One of the most consequential design decisions is where inter-VLAN routing happens. That determines which device sees the traffic and therefore where the boundary can actually be enforced.

If the VLAN gateways live on a layer-3 switch, inter-VLAN traffic is routed there. If those networks are supposed to be isolated from one another, the switch or another control in the path must enforce that distinction through mechanisms such as ACLs, VRFs or equivalent policy. Creating the VLANs themselves does not provide that policy.

If the VLAN gateways terminate on a firewall, the inter-VLAN traffic crosses the firewall's policy engine. That gives the design an obvious place to apply security policy, inspect flows and log the traffic crossing from one network to another.

Product defaults and policy models differ, so the useful statement is not that one kind of device permits and another denies. Gateway placement determines which control actually sees the inter-VLAN traffic. If the control you expect to enforce segmentation is not in the path, it cannot enforce it.

The flows nobody wrote down

Segmentation projects fail in a predictable way. The segments are built, policy is applied, enough things break within a fortnight that somebody adds a broad permit to stop the phone ringing, and six months later the permits carry the traffic while the segments carry the documentation.

This happens because the intended flows were never written down before enforcement started. Not the obvious ones. The ones nobody thinks about until they stop:

• the print server
• the badge readers
• the label printer in the warehouse talking to a host in another segment over a port nobody can name
• the backup agent
• the monitoring poller
• the deployment tool that reaches every endpoint
• the license server an engineering application checks against at launch

The useful artifact is a list of intended flows with a source, a destination, a service and a reason. Write that before restrictive policy is applied.

Anything not on the list is a discovery. A discovery is a decision to make rather than a ticket to close with another broad permit.

What actually deserves its own segment

More segments is not automatically better. Each one creates another policy boundary somebody has to understand and maintain. Thirty segments with permissive policy between them are worse than six that are actually enforced, because the first design costs more while claiming more.

A useful criterion is that two things belong in different segments when they have meaningfully different trust levels, management models or blast radii. That usually produces a fairly short list:

• devices that cannot be patched or centrally managed and were never designed for a corporate network, including many building systems, cameras, sensors and older lab equipment
• devices belonging to people who do not work for the company
• managed corporate endpoints
• servers and infrastructure
• network-management interfaces
• systems inside a specific compliance scope where segmentation prevents that scope expanding across the wider environment

Guest wireless deserves its own line. Separating guests from the internal network is standard and is usually handled correctly. Separating guests from each other is a different control, and the two are worth keeping distinct.

The segment that talks to everything

Most environments develop a highly connected management plane. It is better to recognize it deliberately than discover it during an incident.

Directory services, DNS, DHCP, monitoring, backup, endpoint management, patching and similar infrastructure often need privileged relationships into many otherwise separate parts of the environment. That creates an important asymmetry. The organization may have carefully reduced connectivity between user, server, guest, IoT and production networks while maintaining management systems that legitimately reach into several or all of them.

If those management systems are compromised, those trusted relationships can undermine much of the practical isolation created elsewhere. That makes the management plane one of the highest-value areas of the network rather than ordinary plumbing. It deserves:

• tighter administrative access
• restricted administrative source systems
• dedicated logging
• policies naming specific hosts and services where practical
• avoidance of whole-subnet, any-service access unless there is a genuine technical requirement

You can carefully segment the environment and then undermine much of the design through an over-permissive management plane.

The firewall cannot log traffic it never sees

Traffic between two hosts in the same IP subnet on the same VLAN normally stays at layer 2 and does not cross that subnet's gateway. That means a gateway firewall does not evaluate or log that flow.

The distinction matters. It is not necessarily traffic that the firewall explicitly permitted. It is traffic that never encountered that firewall.

This becomes particularly important after an incident. A common lateral-movement question is what else did this host reach. A particular firewall can answer that only for traffic that crossed it and was logged there. Communication between systems inside the same layer-2 segment may sit outside that record entirely.

Two design choices can reduce that blind area. The first is using smaller segments where the risk justifies it, so that more traffic crosses an enforcement point. The second is using controls such as private VLANs, port isolation or equivalent host-isolation mechanisms where endpoints have no legitimate reason to communicate directly with each other. That can be useful for guest networks, printers, cameras and some IoT networks.

The point is not that every network requires microsegmentation. The point is that segmentation determines more than reachability. It also determines which traffic becomes visible to the controls you expect to inspect it.

The check worth running

Take a laptop and place it in the internal segment you consider least trusted. Try to reach a sensitive management interface such as a network switch, a firewall, a hypervisor or another infrastructure-management endpoint. Then repeat the test from an ordinary managed-user segment.

For each test, establish whether the connection succeeds, which enforcement point sees it, and which policy actually permits or denies it.

If the least-trusted internal segment can directly reach management infrastructure, the claimed segmentation has a serious enforcement problem. If an ordinary corporate endpoint can directly reach sensitive management interfaces without going through a deliberate administrative path, the management plane is not meaningfully isolated. Counting VLANs will not tell you either of those things.

Companion technical note: The deny rule that never fires

Explore this expertise: Network & Infrastructure

All technical notes