The short answer
How to Configure VLANs on a Control Network
To configure VLANs on a control network, map each security zone to a VLAN ID and a subnet, create the VLANs on every switch, set each device port as an access port in the VLAN of its zone, set the links between switches and to the firewall as 802.1Q trunks that carry only the VLANs needed, move the native VLAN off VLAN 1 to an unused ID, put switch management in its own VLAN, configure the firewall as the gateway for every VLAN so that traffic between zones passes its rules, and verify that devices reach their own zone and cannot reach another without a rule.
Key points
- A VLAN is a separate broadcast domain on shared switches; it is only a security boundary when a firewall sits between VLANs.
- One VLAN per zone, one subnet per VLAN, the same IDs at every site.
- Device ports are access ports. Only switch-to-switch and switch-to-firewall links are trunks, and trunks carry only the VLANs they need.
- Nothing lives on VLAN 1. Set the native VLAN on every trunk to an unused ID.
- Switch management goes in its own VLAN, reachable only from the engineering zone.
- Route between VLANs at the firewall, never on a layer 3 switch that bypasses it.
What you need
- The zone and conduit diagram with the VLAN ID and subnet for each zone
- The IP schedule with every device, its VLAN, switch, and port
- Console access to every managed switch and the firewall
- The switch vendor manual for the VLAN and trunk commands
- A laptop that can be moved between ports for testing
- A backup of every switch configuration before starting
Procedure
- 1
Map zones to VLANs
Take the zone diagram and assign a VLAN ID and a subnet to each zone, using the same IDs at every site: VLAN 10 for the control zone, 20 for supervisory, 30 for remote I/O, 99 for switch management, for example. Write the plan as a table before touching a switch.
- 2
Back up every switch
Export the running configuration of every switch and the firewall to a file with the date. A VLAN change that goes wrong is undone by restoring the file, not by remembering what you typed.
- 3
Create the VLANs on every switch
Every switch that carries a VLAN must have it defined, including switches that only pass it through. Name each VLAN with its zone so the name shows in status displays.
- 4
Configure access ports
Each device port is an access port in the VLAN of its zone. Disable trunk negotiation on access ports; a device port that can be talked into becoming a trunk is a way into every VLAN. Add a port description with the device tag.
- 5
Configure trunks
Links between switches and to the firewall are 802.1Q trunks. Restrict each trunk to the VLANs it must carry; a trunk that carries everything by default lets a mistake on one switch reach every zone.
- 6
Move the native VLAN
Frames without a tag on a trunk land in the native VLAN, which is VLAN 1 by default on most switches. Set the native VLAN on every trunk to an unused ID such as 999, and put no ports in it, so untagged frames from a misconfigured device go nowhere.
- 7
Set up the management VLAN
Give each switch its management address in the management VLAN, remove the address from VLAN 1, and allow the management VLAN only on trunks that reach the engineering zone. Confirm you can still reach the switch before you disconnect the console cable.
- 8
Configure the firewall as gateway
Create a sub-interface on the firewall for each VLAN with the .1 address of that subnet, and write the rules that allow the intended conduits between zones. Devices in different VLANs can now talk only through those rules.
- 9
Move devices zone by zone
For each zone: readdress the devices if their subnet changed, move their ports, move their clients, and confirm communication returns before starting the next zone.
- 10
Verify and document
Test reachability within and between zones as described below. Save the configuration on every switch, export a fresh backup, and update the network drawing and IP schedule with the VLAN IDs and port assignments.
Example VLAN plan
| VLAN | Name | Subnet | Members |
|---|---|---|---|
| 10 | CONTROL | 10.5.10.0/24 | Controllers, local HMI panels |
| 20 | SUPERVISORY | 10.5.20.0/24 | SCADA servers, historian, operator workstations |
| 30 | IO | 10.5.30.0/24 | Remote I/O adapters, drives, Ethernet instruments |
| 40 | DMZ | 10.5.40.0/24 | Data relay, remote access jump host |
| 99 | MGMT | 10.5.99.0/24 | Switch and firewall management interfaces |
| 999 | NATIVE | none | Native VLAN on trunks; no members |
Example switch configuration
Command-line syntax varies by vendor, but the objects are the same everywhere: a VLAN database, access ports, trunks with an allowed list and a native VLAN, and a management interface. This example uses IOS-style syntax, which also applies to the industrial switches built on it.
vlan 10
name CONTROL
vlan 30
name IO
vlan 99
name MGMT
vlan 999
name NATIVE
!
interface GigabitEthernet1/0/5
description PLC-101
switchport mode access
switchport access vlan 10
switchport nonegotiate
spanning-tree portfast
!
interface GigabitEthernet1/0/24
description TRUNK-to-FW
switchport mode trunk
switchport trunk native vlan 999
switchport trunk allowed vlan 10,20,30,40,99
!
interface Vlan99
ip address 10.5.99.2 255.255.255.0
!
no interface Vlan1Switches configured through a web page use the same terms: a VLAN table, a port VLAN membership page with untagged for access and tagged for trunk, a PVID that is the native VLAN of a port, and a management VLAN setting.
Verification
- Every switch shows the same VLAN list, and each trunk shows the intended allowed VLANs and native VLAN.
- A laptop on an access port in VLAN 10 pings devices in VLAN 10 across the trunk between switches.
- The same laptop cannot ping a device in VLAN 20 or 30 unless a firewall rule permits it, and the firewall log shows the denied attempt.
- Switch management pages answer only from the engineering zone.
- Nothing has a port in VLAN 1 or in the native VLAN.
- All controller, HMI, historian, and I/O connections are restored, and the configuration is saved and backed up.
Frequently asked questions
- Is a VLAN a security boundary?
- Only with a firewall between VLANs. Two VLANs on the same switch with no router between them cannot talk, which isolates them, but the moment a layer 3 switch or a router joins them the boundary is whatever that device enforces. Route between zones on the firewall, where rules and logs exist.
- Why not use the layer 3 switch to route between VLANs? It is faster.
- It is also unfiltered and unlogged unless access lists are written and maintained on it, which rarely happens. Control traffic between zones is small; a firewall handles it without difficulty. Reserve switch routing for cases where the firewall is the documented bottleneck, and then write the access lists.
- What is the harm in using VLAN 1?
- It is the default for every port and every trunk native VLAN, so a new switch, a reset switch, or a forgotten port lands in it, and management traffic on it mixes with anything untagged. Keeping VLAN 1 empty means those defaults land in a VLAN that connects to nothing.
- How do I add a VLAN to an unmanaged switch?
- You cannot. An unmanaged switch passes tagged frames without understanding them, which sometimes works between two managed switches, and puts every device on it in whatever VLAN its uplink port is assigned. Replace unmanaged switches in the path with managed ones before building VLANs.
Related topics
- How to Assign IP Addresses on a Control NetworkBuild an addressing plan before the first device is configured: one subnet per zone and site, a fixed block layout so an address says what the device is, static addresses on everything that controls a process, and a schedule that is kept current.
- Zones and ConduitsThe IEC 62443 way to segment a control system: grouping assets into zones with a shared security level, inventorying every conduit between them, and turning the drawing into firewall rules. With a worked water utility example.
- Industrial DMZ DesignThe buffer zone between the business network and the control system: what goes in it, the no-direct-path rule, push-not-pull data flows, the firewall pair, and the services a utility actually needs to place there.
- Firewall Rule DesignWriting the rule set for a control network boundary: default deny, one rule per conduit with its reason, hosts not subnets, protocol and port and function, direction and initiator, logging on every rule, and the review that removes forgotten rules.
- Industrial FirewallsFirewalls built for control networks: how they differ from office firewalls, where they belong in a utility network, transparent versus routed modes, Modbus and DNP3 awareness, logging, and the ruggedized units that protect one controller or a remote site.
- How to Troubleshoot an Ethernet ConnectionWork an Ethernet problem one layer at a time: link light and cable, then speed, duplex, and VLAN on the switch port, then address, mask, and gateway, then the application port through the firewall. Each layer has a one-minute test that rules it in or out.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.