Segmenting Your Home Network with VLANs

What you'll build and why

One flat network means every device can, by default, talk to every other device. A smart plug from a manufacturer you don't fully trust sits on the same network as your laptop and your NAS. A guest's phone, once given the Wi-Fi password, can see your printer, your file shares, everything. VLANs fix this: separate logical networks on the same physical switch, with the firewall deciding exactly what's allowed to cross between them.

This guide builds four VLANs: Trusted (your own devices), IoT (smart home devices), Guest (visitors), and Management (the switch/AP admin interfaces themselves, isolated from everything else). Each gets its own subnet, its own DHCP scope, and firewall rules that default to isolated -- nothing crosses between VLANs unless a rule explicitly allows it.

Don't build this if: you haven't completed the OPNsense base build yet, or your switch is unmanaged (this guide cannot help you work around that -- VLAN tagging is a hardware/firmware capability, not a software one). You also don't need four VLANs if your actual goal is just "isolate my IoT devices" -- a single IoT VLAN added to an otherwise flat trusted network is a smaller, faster win if that's genuinely all you need; this guide's four-network design is for readers who want the fuller separation.

How it works

  Trusted VLAN 10  (192.168.10.0/24)
IoT VLAN 20      (192.168.20.0/24)
Guest VLAN 30    (192.168.30.0/24)
Management VLAN 99  (192.168.99.0/24)
Default policy, every VLAN: allow internet out, block
everything else -- including every other VLAN.
Trusted   IoT    Guest   Mgmt
Trusted        --    allow*  block   allow
IoT           block    --    block   block
Guest         block   block   --     block
Mgmt          block   block  block    --
* Trusted -> IoT is a deliberate, narrow exception
(Step 5), not a default -- e.g. your phone reaching
a smart-home hub's specific port, not full access.

Everything defaults to blocked between VLANs. Exceptions are added one at a time, deliberately, for a specific reason -- not by loosening the default policy broadly. This is the same "default deny, allow specifically" principle the base OPNsense build already uses for WAN, just applied between your own internal networks too.

Before you start

Plan your VLAN IDs and subnets before touching the switch or OPNsense. This guide uses:

VLAN 10  Trusted     192.168.10.0/24
VLAN 20  IoT         192.168.20.0/24
VLAN 30  Guest       192.168.30.0/24
VLAN 99  Management  192.168.99.0/24

Substitute your own numbering if you prefer, but keep it consistent across every device you configure -- a mismatched VLAN ID between the switch and OPNsense is the most common reason this doesn't work on the first attempt.

Nothing on your existing trusted network needs to move for this to start working -- you're adding new VLANs alongside it, then deciding what (if anything) migrates to IoT/Guest afterward.

Steps

Step 1: Create the VLAN interfaces in OPNsense

Interfaces → Other Types → VLAN → Add for each of the four VLANs: set the parent interface (your LAN-facing NIC) and the VLAN tag (10, 20, 30, 99). Repeat four times.

Editor's note on this step's verification: the menu path above matches established OPNsense/pfSense-family convention and is consistent with OPNsense's confirmed Interfaces → Assignments pattern (used elsewhere in this guide and the prerequisite), but wasn't independently re-confirmed against a dedicated OPNsense VLAN documentation page this session -- two direct attempts to fetch one returned 404. If your installed version's menu differs, check docs.opnsense.org's current Interfaces section directly.

Step 2: Assign and configure each VLAN interface

Interfaces → Assignments: assign each of the four new VLAN devices as an interface. For each: enable it, give it the static IP from your plan (e.g. 192.168.10.1/24 for Trusted), and a clear description matching its purpose.

Step 3: Enable DHCP on each VLAN

Services → DHCPv4 → [VLAN interface] for each of the four: enable, set a range within that VLAN's subnet (e.g. 192.168.10.100-192.168.10.200 for Trusted).

Step 4: Set default-deny firewall rules between VLANs

Firewall → Rules → [VLAN interface] → Add, for each VLAN: one rule allowing outbound internet access, and confirm there is no rule allowing access to the other three VLAN subnets -- OPNsense's default is already deny-unless-allowed per interface, so the key check here is confirming you haven't accidentally added a broad "allow all" rule that defeats this (remember rule order: first match wins, top to bottom, from the base guide).

Step 5: Add deliberate, narrow exceptions where you actually need them

A common real case: your phone (Trusted) needs to reach a smart-home hub (IoT) to control it. Firewall → Rules → Trusted → Add: source Trusted subnet, destination the specific IoT device's IP (not the whole IoT subnet), destination port the specific service needs (not "any"). This is the pattern for every exception -- as narrow as the actual need, never a blanket allow between two VLANs.

Step 6: Move devices onto their VLANs

For wired devices: connect them to a switch port configured (on the switch itself, not in OPNsense) to carry the relevant VLAN, untagged, for that device. For wireless devices: if your access point supports it, create a separate SSID per VLAN (at minimum, Trusted and IoT/Guest as distinct SSIDs) and map each to its VLAN.

Verify it works

• A device on the Trusted VLAN gets an address in 192.168.10.0/24 and has internet access
• A device on the IoT VLAN gets an address in 192.168.20.0/24, has internet access, but cannot reach a device on the Trusted VLAN (test: try to ping or connect from the IoT device to something on Trusted -- it should fail)
• The Step 5 exception works in the specific direction and scope you configured it -- and only that scope (confirm the IoT device still can't reach anything else on Trusted beyond what you explicitly allowed)
• Failure test: connect a device to a switch port you think is configured for the Guest VLAN, but verify its actual assigned address is in the Guest subnet (192.168.30.0/24), not accidentally the Trusted one -- this specific check catches the single most common real-world failure mode (a mistagged or forgotten switch port), which a config review inside OPNsense alone won't reveal

Secure it

• What's exposed: nothing new beyond the base OPNsense build -- this guide is itself a security improvement, not a new exposure. The Management VLAN specifically should have the narrowest access of all four: only your own admin devices should be able to reach switch/AP management interfaces, not even the general Trusted VLAN by default.
• The failure that hurts most: a switch port left on the default/native VLAN (often VLAN 1, untagged) that you believe is isolated but isn't -- this bypasses every firewall rule you wrote, because the traffic never reaches OPNsense's VLAN-aware interfaces the way you assumed. The step that prevents it: explicitly check every switch port's VLAN assignment, don't assume an unconfigured port defaults to isolated -- on most switches, it defaults to VLAN 1, which may still have broader access than you intend.
• Guest network specifically: beyond VLAN isolation, consider whether the Guest VLAN should also be time-limited or bandwidth-limited -- outside this guide's scope, but worth deciding deliberately rather than leaving guest access unlimited by default.

Back it up and maintain it

What matters: this is entirely OPNsense configuration -- covered by the same System → Configuration → Backups → Download configuration export as the base build. Export again after completing this guide, since it's a meaningful config change from your backed-up base state.

What to monitor: Firewall → Log Files, filtered to inter-VLAN traffic occasionally, to confirm isolation is holding and to catch legitimate needs for a new narrow exception before someone works around your firewall to get something to work.

Troubleshooting

Logs: Firewall → Log Files → Live View, filtered by the specific VLAN interface you're debugging.

Undo

Remove each VLAN's firewall rules and DHCP configuration, then Interfaces → Assignments to unassign each VLAN interface, then Interfaces → Other Types → VLAN to delete each VLAN definition. On the switch side, return the ports you'd configured back to their previous (typically untagged, native VLAN) state.

Go further

• How VLANs, Trunks, and Tagging Actually Work -- the frame-by-frame conceptual explanation behind what this guide just built
• Add a fifth VLAN for a specific purpose (a homelab-servers-only VLAN, separate from general Trusted) using the same pattern
• Look into per-VLAN traffic shaping if the Guest network needs a bandwidth cap, not just isolation
• If you have a VLAN-aware managed switch with its own web UI, explore its own VLAN visibility/diagnostics -- often faster to check switch-side VLAN assignment there directly than to infer it from OPNsense alone

Resources

Official documentation:

• OPNsense Interfaces documentation -- interface assignment, confirmed this session
• OPNsense Firewall documentation -- rule evaluation, referenced from the prerequisite guide

Source and releases:

• OPNsense core releases

Community:

• OPNsense Forum

Go deeper:

• OPNsense documentation's full manual -- for switch-specific VLAN configuration, which varies by manufacturer and is outside what this guide (an OPNsense-side guide) can cover generically

Related DaemonPress projects:

• Building a Router and Firewall with OPNsense -- the prerequisite this guide builds on
• How VLANs, Trunks, and Tagging Actually Work

Last verified: 2026-09-21, checked against official OPNsense documentation for interface assignment (see Resources above and the editor's note in Step 1 regarding the VLAN-creation menu path specifically).