VLAN firewall rules are where segmentation stops being decoration and starts being security. The rule is brutally simple: default-deny everything between VLANs, then carve narrow allow rules for the exact flows you need — and get the order right, because firewalls match top-down, first-match-wins. I run this rule structure on OPNsense across seven VLANs, and the entire security of the network lives in maybe fifteen deliberate rules.
A VLAN with no firewall rules between it and the others is not isolated — it is just labeled. The switch tags the traffic, but if the firewall happily routes between every subnet, you have built tidy organization, not a boundary. This guide is the rule recipes I actually use: the ordering, the anti-lockout rule that saves you from yourself, the allow-to-gateway trick, and the RFC1918 alias I reuse everywhere. It is the firewall half of the home network VLAN guide.
Default-Deny Is the Only Correct Posture
Default-deny means every VLAN starts with “block all traffic to other VLANs,” and you add explicit allow rules only for the specific flows you actually need. This inverts the consumer-router default of allow-everything, and it is the single most important decision in the whole build. Everything else is just deciding which narrow holes to poke.
Here is why it matters in practice. If you start from allow-all and try to block the bad stuff, you will always miss something — there are infinite paths to block. If you start from deny-all and allow only the known-good stuff, the unknown is blocked by default, which is exactly what you want from a device you do not fully trust. My IoT VLAN, for example, has precisely zero allow rules to other VLANs; it can reach a DNS server and the internet whitelist and nothing else. That is default-deny doing its job — the absence of an allow rule is the security.
Rule Order: First-Match-Wins Is Everything
Firewalls evaluate rules from top to bottom and stop at the first match, so a broad allow placed above a specific block means the block never executes. This is the mistake that silently destroys segmentation, and it is the thing I check first whenever someone says “my VLAN rules are not working.” Specific rules go on top; broad rules go below.
The structure I put on every isolated VLAN interface, in this exact order:
- Anti-lockout / allow to gateway: allow this VLAN to reach its own firewall gateway on DNS (53) and DHCP (67) so basic networking functions.
- Block to firewall admin: block this VLAN to “This Firewall” on the admin ports so clients cannot reach the GUI or SSH.
- Specific inter-VLAN allows: the deliberate exceptions, e.g. TRUST → NAS on SMB, TRUST → IoT on the control port.
- Block to RFC1918: block this VLAN to all private ranges via an alias — this is the wall that contains the segment.
- Allow to internet: allow to “any,” which by this point is only the public internet because the private ranges are already blocked above.
Read that order carefully: the specific allows (step 3) sit above the RFC1918 block (step 4), so they win for the flows you want, while everything else falls through to the block. Flip steps 3 and 4 and your deliberate allows die. This ordering is identical in spirit on pfSense and OPNsense — only the UI differs. For the platform-specific click-throughs, my OPNsense firewall rules tutorial and pfSense firewall rules guide walk the GUI.
Aliases: Write the Rule Once, Reuse It Everywhere
An alias is a named group — like RFC1918 containing the three private ranges, or IoT_Controllers containing your hub IPs — that you reference in rules instead of typing addresses. Aliases turn a sprawling ruleset into a readable one and mean a change in one place updates every rule at once. I never write a raw private-range block; I reference the alias.
The aliases I keep on every build:
RFC1918= 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — the private-range block target on every isolated VLAN.This_Firewall— the firewall’s own VLAN gateway IPs, for the admin-block rule (OPNsense provides a built-in equivalent).NAS— the storage box, so TRUST → NAS rules read clearly.IoT_Controllers— the specific IoT device IPs my phone needs to reach.
When I add a new VLAN, I do not rewrite the isolation logic — I drop in the same RFC1918 block referencing the same alias and the segment is contained on day one. This is also how I keep the guest VLAN and the IoT VLAN using identical, verifiable isolation: same alias, same rule, different interface.
Stateful Rules and the Reachable-But-Not-Reaching Pattern
Stateful firewalls automatically allow return traffic for an allowed connection, which lets you build asymmetric access: TRUST can open a connection to an IoT device, but the IoT device can never open one back. You write one allow rule in one direction, and the firewall handles the return packets — you do not, and must not, open the reverse direction.
This is the pattern that makes segmentation usable instead of just locked-down. My phone on TRUST needs to control the smart plugs on IoT. I add one rule: allow TRUST → IoT_Controllers on the control port. Because the firewall is stateful, the plug’s reply comes back automatically. But the IoT VLAN itself has no rule allowing it to initiate toward TRUST, so a compromised plug cannot start a connection inward — it can only answer ones my phone started. That asymmetry is the heart of the IoT VLAN design, and it falls straight out of stateful rules plus default-deny.
The Rule Recipes I Run Per VLAN
Different VLANs need different policies, but they are all variations on the same default-deny skeleton. The table below is the actual policy I run per zone — read it as a cheat sheet for what allow rules to add on top of the universal block-to-RFC1918 base.
| VLAN | Allow to gateway | Specific inter-VLAN allows | Internet | Net effect |
|---|---|---|---|---|
| TRUST | Yes | → NAS, → IoT control ports, → MGMT admin | Full | The one zone that can reach others |
| GUEST | DNS/DHCP only | None | Full (rate-limited) | Internet and nothing else |
| IOT | DNS only | None (only answers TRUST) | Whitelist / none | Caged; cannot initiate out |
| KIDS | Yes (filtered DNS) | None | Full | Internet only, stricter DNS |
| WORK | Yes | None | Full | Isolated from home zones |
| MANAGEMENT | Yes | Reachable only from TRUST admin | Updates only | The crown jewels, locked down |
The Anti-Lockout Rule That Saves You
Before you deploy a deny rule on the VLAN you are managing the firewall from, make sure an anti-lockout or allow-to-gateway rule sits above it — otherwise you will block your own admin session and lose access to the box. This is the single most common self-inflicted disaster in VLAN firewalling, and I have done it myself in the early days.
OPNsense and pfSense both ship an anti-lockout rule for the management interface by default, but the moment you start hardening you can defeat it. My habit: I build and test rules on a VLAN I am not connected through, and I keep a serial console cable in the drawer for the day I lock myself out anyway. If you do get locked out, the console is the recovery path — you cannot fix a firewall rule from a network the firewall is now blocking. Build the allow-to-gateway rule first, every time, before any block.
How I Verify the Rules Actually Hold
A rule you have not tested is a hope, not a control. After deploying, I verify isolation from the wrong side: from a guest or IoT device, I try to ping and port-scan an internal host, and confirm the firewall drops it. Then I check the live firewall log to see the block rule actually firing.
My verification routine is quick: from a device on the isolated VLAN, attempt to reach the NAS by IP — it should time out. Attempt to reach the firewall admin GUI — refused. Then from TRUST, confirm the allowed flow (controlling an IoT device) still works. Finally I watch the firewall’s live log and confirm the RFC1918 block rule is incrementing its hit counter when the isolated device tries to reach inward. If the block counter never moves, traffic is matching an earlier rule and your order is wrong. This testing loop is part of the broader security hardening discipline, and it sits naturally alongside the wider network segmentation plan.
Frequently Asked Questions
What are VLAN firewall rules?
VLAN firewall rules govern what traffic is allowed to cross between your VLANs. The correct approach is default-deny: block all inter-VLAN traffic by default, then add narrow allow rules for the specific flows you need. Without these rules a VLAN only organizes traffic; the firewall rules are what actually enforce isolation between segments.
Why is rule order important in a firewall?
Firewalls evaluate rules top to bottom and stop at the first match, so order determines behavior. A broad allow placed above a specific block means the block never runs. Always put specific allow rules on top, then your block-to-private-ranges rule, then the broad allow-to-internet rule last. Wrong order silently breaks segmentation.
How do I block one VLAN from reaching another?
Add a block rule on the source VLAN interface targeting an RFC1918 alias that contains 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, placed above the allow-to-internet rule. Because the private ranges are blocked first, the device can still reach the internet but cannot reach any other internal VLAN.
What is a stateful firewall rule?
A stateful firewall automatically permits return traffic for a connection it already allowed, so you only write a rule in one direction. This lets you allow your trusted devices to reach an IoT device while the IoT device can never initiate a connection back. The return packets are handled automatically; you never open the reverse direction.
How do I avoid locking myself out of the firewall?
Always place an anti-lockout or allow-to-gateway rule above any deny rule on the VLAN you manage the firewall from. Build and test new rules on a VLAN you are not connected through, and keep a serial console cable handy for recovery. If you block your own admin path, only console access can restore it.
Do firewall rules between VLANs slow down my network?
No, not on capable hardware. Inter-VLAN routing and rule evaluation happen at the firewall, and any modern x86 appliance handles gigabit between VLANs easily. Traffic that stays within a single VLAN is switched at line rate and never reaches the firewall, so the rules add no overhead to same-VLAN traffic at all.
What firewall rules should an IoT VLAN have?
An IoT VLAN should allow only DNS to the gateway, block everything to the firewall admin and to all RFC1918 ranges, and have no rule letting it initiate connections outward except a tight internet whitelist if needed. Your trusted VLAN gets one stateful allow rule to reach IoT control ports, and the firewall handles the replies.
This guide is part of the VLAN and network security cluster on the HomeLabRouter homepage, where I document the whole segmented setup I run at home.