Campus network segmentation design for a mid-size business

Most office networks we walk into have the same shape. One subnet, one VLAN, one firewall rule that says "allow all." Laptops, the file server, printers, door controllers, TVs, and guest Wi-Fi all share it. Campus network segmentation is the fix, and it is less work than most IT managers expect once the design is right.

CISA describes segmentation as dividing a network, physically or virtually, into segments that each act as their own subnetwork. It makes an attacker's second move harder, makes abnormal traffic easier to spot, and keeps a compromised printer from becoming a path to payroll.

Who has a flat network, and how to tell

The test takes a minute. From a laptop on the office network, try to reach a printer's management page, a camera's web interface, and a file share on a server. If all three answer, the network is flat, whatever the diagram says.

The companies this describes usually run 50 to 500 users on Cisco Catalyst or Meraki MS switches, a Meraki MX or Cisco Secure Firewall at the edge, and Meraki or Catalyst wireless. The gear is capable. The design was never done, or it was done years ago and every device since has landed in the default VLAN. CISA notes in its segmentation infographic that boundary protection has been the most common finding in its network architecture assessments since 2015. We see the same thing in the mid-size networks we assess.

What a flat network costs you

The cost shows up on the worst day, when the flat network becomes the blast radius. One phished laptop can reach every server, every backup target, and every unpatched embedded device in the building.

It also shows up on ordinary days. Insurance questionnaires ask whether guest, IoT, and production traffic are separated. A PCI assessor asks what is in scope, and on a flat network the honest answer is "everything." Either one is a compliance finding or a declined claim, and both cost more than a design project.

A segmentation design that fits a mid-size campus

The right number of segments is small. Six to eight zones cover almost every mid-size business; more creates rules nobody maintains. Here is the design we start from.

Users. Corporate laptops and desktops. The only zone that reaches the servers broadly, and only on the ports the applications use.

Servers. File, print, directory, line-of-business applications. Nothing here should initiate connections to user devices. Backup targets get their own subnet or zone so a compromised server cannot reach them directly.

Printers and IoT. Printers, cameras, TVs, badge readers, HVAC controllers. Each needs a print server, a recorder, or a cloud service and nothing else.

Operational technology. If you run a plant floor, warehouse controls, or building automation, CISA's guidance is specific: put high-value and OT assets in their own high-security zone behind firewall access controls, with a DMZ for anything that must talk to both sides. Only named devices in that DMZ reach the OT assets, and only on specified connections.

Guests. Internet only, with local LAN access denied. Meraki documents this as a wireless firewall rule that blocks RFC 1918 destinations. Most offices already have it. Check it anyway.

Management. Switch, access point, firewall, and hypervisor management interfaces, reachable only from a jump host or the IT team's subnet.

Where the enforcement point sits

Every zone boundary needs a device that can say no. For a 50-user office with a Meraki MX, the MX routes between VLANs and its Layer 3 firewall rules govern what crosses. Two details from the Meraki documentation matter. The MX treats traffic from one VLAN to another as outbound, so inter-VLAN rules live in the outbound rule set. And the last rule is an unmodifiable allow-all, so a network with VLANs and no explicit deny rules is still flat. The deny rules are the design.

For a 200-to-1,000-user campus, routing between user VLANs belongs on a Layer 3 distribution or collapsed-core switch, and the firewall sits between the campus and the server, OT, and internet zones. Cisco's campus design guide describes the two-tier collapsed core as the fit for smaller LANs, with a separate core layer appropriate once three or more distribution blocks connect. The practitioner's rule: switch ACLs enforce the simple boundaries, and the stateful firewall enforces anything that touches servers, OT, or the internet, where you need logging and inspection.

Keep VLANs small and local

Cisco's guide recommends restricting a Layer 2 VLAN to a single wiring closet or access uplink pair in a traditional design. Meraki's campus guidance agrees from the wireless side: avoid large broadcast domains, assign VLANs per zone or floor, and keep roaming zones small. A single /16 users VLAN stretched across three buildings fails both tests.

Where NAC-driven dynamic segmentation fits

Static VLAN assignment breaks the first time a printer is moved to a user's desk port. Network access control fills that gap. With 802.1X or MAC authentication, the RADIUS server identifies the device and the switch or access point places it in the right segment. On Meraki, the RADIUS response can carry a Tunnel-Private-Group-ID that overrides the SSID VLAN, or a group policy attribute that applies firewall rules to the client. Cisco ISE returns the same results to Catalyst and Meraki gear alike.

The step past VLANs is group-based policy. Cisco's campus guide ties micro-segmentation to TrustSec security group tags, and Meraki implements the same tagging as Adaptive Policy on supported MS, MR, and MX hardware with Advanced or Advantage licensing. A tag follows the device and the policy reads as "cameras may talk to the recorder," with no IP addresses in it. Meraki's documentation notes that moving a wired client between VLANs disrupts it while changing its tag does not, which is why ISE quarantine integrations use tags.

This is where NIST SP 800-207 lands. Zero trust, as NIST defines it, grants no implicit trust based on network location, and the document describes a micro-segmentation deployment model in which switches, routers, or next-generation firewalls act as enforcement points in front of each resource. VLANs and zones are the foundation that model is built on. Our managed and co-managed NAC practice exists because dynamic assignment is the part that needs ongoing operation.

What to do first with the gear you own

1. Inventory by function. List every device class on the network and which other classes it must reach. This table is the design. Everything else is typing.
2. Create the guest, printer/IoT, and management VLANs first. They have the simplest rules and the biggest payoff. Leave users and servers in the existing VLAN for now.
3. Write explicit deny rules before you move anything. On an MX, confirm VLANs are enabled in routed mode, then add outbound rules that block IoT and guest from the server and user ranges. On Catalyst, apply the equivalent ACLs on the SVIs.
4. Move devices in a maintenance window, one class at a time. Printers first; the failure mode is obvious and recoverable.
5. Split servers from users last. This boundary breaks the most applications. Log before you block, review two weeks of what crossed, then enforce.
6. Plan NAC after the static design is stable. Dynamic assignment onto a bad VLAN plan automates the mistakes.

When to get help

If your network is one subnet and you run Catalyst or Meraki, the design above is a scoped project on the equipment you already own, and it is work our network security team does regularly. If you have VLANs but no deny rules, or OT sharing a wire with the office, that is the point to talk to us. The first step is a 30-minute intro call where we listen to how your network is built today.