OPNsense VLAN Configuration: Segment IoT, Guest, and Trusted

Proper network segmentation prevents your smart TV from talking to your NAS. This guide covers creating VLANs in OPNsense and the firewall ↗ rules that make segmentation actually work.

Before you start, a reality check: VLANs only provide isolation if three things are all true — the OPNsense sub-interfaces are tagged correctly, the managed switch trunks/accesses those VLANs correctly, and the firewall rules on each VLAN interface actually block inter-VLAN traffic. A VLAN with no restricting firewall rule is just another flat network with extra steps. You also need a switch that supports 802.1Q VLAN tagging and an AP that supports either multiple SSIDs mapped to VLANs or a VLAN trunk. A single dumb switch cannot enforce any of this.

Design: Three-VLAN baseline

VLAN ID	Name	Subnet	Purpose
10	TRUSTED	192.168.10.0/24	Workstations, servers, phones you control
20	IOT	192.168.20.0/24	Smart home devices, printers, cameras
30	GUEST	192.168.30.0/24	Guest Wi-Fi — internet only

Step 1: Create VLANs

Interfaces → Other Types → VLAN → Add:

• Parent interface: your LAN NIC (e.g., igb1)
• VLAN tag: 10
• Description: TRUSTED

Repeat for VLAN 20 (IOT) and VLAN 30 (GUEST).

The VLAN tag must match exactly what the switch sends on the trunk. The parent interface here should be the physical LAN NIC; you do not assign an IP to the parent — it carries only tagged frames.

Step 2: Assign interfaces

Interfaces → Assignments. Each new VLAN appears in the “new interface” dropdown — add it, then it shows up as OPT1/OPT2/OPT3 (rename them TRUSTED/IOT/GUEST under Interfaces → [name] → Description so rules stay readable). For each:

• Enable the interface
• Set IPv4 Configuration Type to Static IPv4
• Assign the gateway address for that subnet (e.g., 192.168.10.1/24 for TRUSTED) — this is the address clients will use as their default gateway
• Save, then Apply changes

Then enable a DHCP scope per VLAN: Services → DHCPv4 → [interface] → enable, set a range inside the subnet (leave the .1 gateway out of the pool), and set DNS to the OPNsense VLAN IP if you want per-VLAN DNS filtering. Restart the DHCP service after editing scopes. Without a DHCP scope, devices on that VLAN won’t get an address unless statically configured.

Step 3: Firewall rules

IoT VLAN — block all inter-VLAN, allow internet

On the IOT interface:

Action: Block
Protocol: any
Source: IOT net
Destination: 192.168.0.0/8 (RFC1918 aggregate)
Description: Block IoT → private ranges

Action: Pass
Protocol: any
Source: IOT net
Destination: any
Description: Allow IoT → internet

Guest VLAN — internet only, block RFC1918

Same pattern as IoT, applied to the GUEST interface.

Trusted VLAN — full access

Allow all by default (or lock down as needed for your threat model).

Rule ordering and the “block private, then allow internet” pattern

OPNsense evaluates rules on an interface top-down, first match wins. The block-RFC1918 rule must sit above the allow-any rule, or the allow rule will pass inter-VLAN traffic before the block is ever evaluated. A subtle gotcha: the destination “192.168.0.0/8” only covers the 192.168 space. If your other VLANs or LAN live in 10.x or 172.16–31.x, create an alias (Firewall → Aliases) containing all three RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and use that alias as the block destination. Our OPNsense rule and alias recipe generator emits exactly this RFC1918 block alias plus the ordered inter-VLAN isolation rules, ready to paste. This is the single most common reason “my VLAN isolation isn’t working.”

Also remember the default deny: OPNsense drops anything not explicitly passed on an interface, but only inbound on that interface. Each VLAN needs its own rules; rules are not shared between interfaces.

DNS and the management plane

If you point all VLANs at the OPNsense IP for DNS, your block rule to RFC1918 will also block DNS to the firewall. Add a narrow pass rule above the block: allow IOT/GUEST → “This Firewall” on UDP/TCP 53 (and 853 if you use DoT). Similarly, if a VLAN needs NTP from the firewall, permit UDP 123 to “This Firewall” explicitly. Decide deliberately whether IoT devices may even reach the GUI — usually they should not, so do not add a pass to ports 80/443 of the firewall from IOT.

Step 4: Test segmentation

From an IoT device, confirm:

ping 192.168.10.1   # Should fail (blocked by firewall rule)
curl https://example.com   # Should succeed

If ping to the gateway fails too, you’ve likely got a switch tagging problem, not a firewall problem — verify the next section first.

Managed switch tagging

This is where most VLAN setups actually break. The port from the switch to OPNsense must be a trunk (tagged) port carrying VLANs 10, 20, and 30. The ports facing end devices are access (untagged) ports with their PVID set to the device’s VLAN — the switch tags ingress frames and strips the tag on egress so the device sees plain Ethernet. The OPNsense parent NIC must be the trunk; the sub-interfaces handle each tag.

Two recurring switch gotchas:

• Native/untagged VLAN mismatch. If the switch sends VLAN 1 untagged on the trunk and OPNsense expects everything tagged, untagged management traffic can leak. Keep the trunk’s native VLAN to something unused, and never put trusted devices on VLAN 1.
• AP trunking. For Wi-Fi, the AP uplink is also a trunk. Map each SSID to a VLAN on the AP; a “guest” SSID that isn’t actually tagged onto VLAN 30 will land on the native VLAN and bypass all your isolation.

Verification at the switch: most managed switches show a VLAN membership table — confirm the OPNsense port is tagged for all three VLANs and each access port is untagged on exactly one.

Running UniFi APs? See UniFiGuide ↗ for SSID-to-VLAN mapping in the Network Application.

When VLAN segmentation is the wrong tool

VLANs are layer-2 isolation enforced by your firewall at layer 3. They are excellent for “IoT can’t reach my NAS” but they are not a substitute for host hardening, and they do not protect against a compromised device on the same VLAN. If your real requirement is isolating two trusted hosts from each other, host firewalls or separate physical networks are more appropriate. And if you only have a handful of devices and a dumb switch, the operational complexity of VLANs may exceed the benefit — a single well-firewalled LAN plus a separate guest SSID on the router may be enough. Add VLANs when you have untrusted device classes (IoT, guests, cameras) that genuinely need to coexist on shared infrastructure.

For more context, Docker homelab tutorials ↗ covers related topics in depth.