Segments, routes, and policy

A café draws three colored boxes: guest Wi-Fi, payment devices, and management. The picture looks reassuring. But colors cannot stop communication. To judge the design, ask three separate questions: which devices share a local domain, which routes connect domains, and which policies allow traffic to cross?

A segment describes a boundary

An Ethernet VLAN groups interfaces into a logical broadcast domain. Devices in different VLANs do not share ordinary layer-2 broadcasts through normal VLAN forwarding. Communication between them needs routing. A layer-3 switch may perform that routing inside the same physical box, so separate hardware is not required.

A subnet describes an IP addressing scope. Many designs pair one subnet with one VLAN, but the terms are not interchangeable definitions. The network drawing should show the actual relationship rather than assume that matching colors or numbers establish it.

A route is a direction, not permission

Routing information says where a packet may be forwarded next. Traffic policy says whether that communication is allowed. These decisions often occur on the same device, which makes them easy to confuse. A correct route can lead to a policy denial; an allow rule cannot repair a missing route.

In the café, guests need access to public internet services but not management interfaces. Payment devices need selected provider services, naming, time, and maintenance dependencies. “Block everything” may break necessary work. “Allow everything internal” makes the boundary too broad. The job is to describe required purposes precisely enough to enforce them.

PredictThe café moves payment devices into a new VLAN, then permits unrestricted routing to and from guests. Has it established a restrictive guest-to-payment boundary?

No. It separated local broadcast domains, but the routing policy still permits broad communication. Segmentation requires the intended cross-boundary restrictions to be enforced, with exceptions justified.

Make a rule understandable

A useful fictional rule identifies a source group, destination, service, direction, business purpose, and responsible owner. A temporary exception also needs an expiry or review condition. Stateful firewalls can associate return traffic with permitted connections, but that behavior depends on protocol support and configuration; it is not permission for arbitrary new inbound sessions.

After the application receives traffic, it still checks identity and authority. The website’s database connection might allow catalog reads but not membership administration. NIST’s zero trust architecture treats network location as insufficient grounds for automatic trust. That principle complements segmentation: limit paths and evaluate access to the resource.

Plan for changes and failures

Cloud services, IPv6, remote administration, and backup paths can introduce additional routes. Keep policy consistent across them. Logs should identify useful allow or deny decisions without collecting unnecessary personal data. When a rule changes, compare intended behavior with the permitted paths, including the return direction. A meaningful boundary is a maintained decision, not a box drawn once and forgotten.