VLANs with OPNsense & Omada

This guide covers planning and implementing a VLAN network using OPNsense as the router/firewall and TP-Link Omada managed switches. It covers the full stack: VLAN design, OPNsense interface and DHCP configuration, firewall rules, NAT, and Omada switch profiles and port assignments.

Concepts

What is a VLAN?

A VLAN (Virtual Local Area Network) logically separates devices on the same physical network into isolated segments. Devices on different VLANs cannot communicate with each other unless explicitly permitted by a router or firewall rule.

Common use cases:

• Isolating IoT devices from trusted workstations
• Separating guest WiFi from internal networks
• Segmenting servers from personal devices
• Creating a dedicated management network for infrastructure

Tagged vs Untagged

Understanding the difference between tagged and untagged traffic is fundamental to VLAN configuration.

Untagged (access ports) Used for end devices that are not VLAN-aware — computers, servers, NAS devices, printers. The device sends a normal ethernet frame with no VLAN information. The switch receives it, stamps the appropriate VLAN tag internally based on the port's profile, and routes it accordingly. On egress, the tag is stripped before delivery to the device. The device never knows VLANs exist.

Tagged (trunk ports) Used for VLAN-aware devices — routers, upstream switches, hypervisors. The device itself includes a VLAN tag in each ethernet frame. The switch receives the frame with the tag intact and uses it to route traffic to the correct VLAN. Trunk ports carry multiple VLANs simultaneously, each identified by its tag.

Router-on-a-Stick

With a single physical port connecting OPNsense to the switch, all VLAN traffic travels over one link — each VLAN tagged. OPNsense creates virtual sub-interfaces (one per VLAN) on top of that physical port. This is the most common homelab setup and works well at any scale that doesn't saturate the uplink.

Planning

VLAN Scheme

Design your VLANs before touching any configuration. A clean numbering scheme that maps to subnets makes the network far easier to manage and troubleshoot.

Recommended pattern: Use the VLAN ID as the third octet of the subnet.

Tip: Leave gaps in your VLAN ID numbering (10, 20, 30 rather than 1, 2, 3) so you can insert new VLANs later without renumbering.

Firewall Policy

Define your inter-VLAN routing policy before writing any rules. This makes the rules themselves straightforward to implement.

IP Address Allocation

Plan static IP allocation to avoid conflicts with DHCP ranges.

Recommended layout per subnet:

OPNsense Configuration

Step 1 — Create VLAN Interfaces

Navigate to Interfaces → Other Types → VLAN.

For each VLAN, click + and set:

Click Save after each entry, then Apply changes.

Step 2 — Assign VLAN Interfaces

Navigate to Interfaces → Assignments.

Each VLAN device you created needs to be assigned as an interface so OPNsense can route for it.

1. At the bottom, select a VLAN device from the Device dropdown
2. Click + Add
3. Repeat for each VLAN
4. Click Save

You will now see each VLAN listed as an interface (OPT1, OPT2, etc.). Click each one to configure it.

Step 3 — Configure Each VLAN Interface

Navigate to Interfaces → [VLAN NAME] for each interface.

Click Save → Apply changes after each interface.

Step 4 — Configure DHCP per VLAN

Navigate to Services → Dnsmasq DNS & DHCP → DHCP ranges.

Add one DHCP range per VLAN interface:

Do not create overlapping ranges. Static reservations (dnsmasq Hosts) do not need their own DHCP range — they sit outside the pool by convention.

Step 5 — Push DNS Server via DHCP

Clients need to receive your DNS server (e.g. AdGuard Home) via DHCP so all DNS queries are filtered.

Navigate to Services → Dnsmasq DNS & DHCP → DHCP options.

For each VLAN interface, add:

Use the gateway IP of the VLAN the client is on (e.g. 10.10.30.1 for the LAB VLAN), not a fixed single IP. This ensures DNS works correctly once the flat LAN is retired.

Step 5a — DHCP Option 138 for Omada Controller Discovery (MANAGEMENT VLAN only)

If you are using a dedicated MANAGEMENT VLAN for Omada switches and APs, you must also configure DHCP Option 138 on the MANAGEMENT interface. This tells Omada devices where the controller is after a reboot — without it, devices survive a single session but become orphaned the moment they reboot.

Navigate to Services → Dnsmasq DNS & DHCP → DHCP options.

This is required because broadcast-based controller discovery does not cross VLAN boundaries. Once a switch is on the MANAGEMENT VLAN, it can only find the controller if told explicitly via Option 138.

Step 6 — Static DHCP Reservations

For servers and infrastructure that need consistent IPs, use static reservations rather than configuring IPs on the devices themselves where possible.

Navigate to Services → Dnsmasq DNS & DHCP → Hosts.

Note: Do not duplicate entries across both Dnsmasq Hosts and Unbound Overrides. Pick one. Unbound Overrides are preferred for DNS records. Dnsmasq Hosts are preferred for DHCP-bound static reservations.

Step 7 — Firewall Rules

Navigate to Firewall → Rules → [Interface tab].

OPNsense processes rules top to bottom, first match wins. Always place block rules above allow rules.

Field Reference

Block vs Reject: Block silently drops packets (client times out). Reject sends an immediate refusal. Use Block for security rules — it gives less information to potential attackers and is the safer default.

MANAGEMENT Rules

One rule — full unrestricted access:

Action:      Pass
Interface:   MANAGEMENT
Direction:   In
Protocol:    Any
Source:      MANAGEMENT net
Destination: any
Log:         No
Description: Management full access

TRUSTED Rules

One rule — full unrestricted access:

Action:      Pass
Interface:   TRUSTED
Direction:   In
Protocol:    Any
Source:      TRUSTED net
Destination: any
Log:         No
Description: Trusted full access

SERVERS Rules

Three rules in this order:

Rule 1 — Block servers from reaching trusted workstations

Action:      Block
Interface:   SERVERS
Direction:   In
Protocol:    Any
Source:      SERVERS net
Destination: TRUSTED net
Log:         Yes
Description: Block SERVERS to TRUSTED

Rule 2 — Block servers from reaching management infrastructure

Action:      Block
Interface:   SERVERS
Direction:   In
Protocol:    Any
Source:      SERVERS net
Destination: MANAGEMENT net
Log:         Yes
Description: Block SERVERS to MANAGEMENT

Rule 3 — Allow servers internet access

Action:      Pass
Interface:   SERVERS
Direction:   In
Protocol:    Any
Source:      SERVERS net
Destination: any
Log:         No
Description: SERVERS internet access

Rule 3 uses any as destination. Rules 1 and 2 above it have already blocked the specific internal targets — any here effectively means everything not already matched.

SERVERS Rules — Exception for Omada Controller

If your Omada controller runs on the SERVERS/LAB VLAN and you have a MANAGEMENT VLAN for switches, you must add an explicit allow rule so the controller can reach the switches. Place this above any block rules on the SERVERS/LAB interface.

Action:      Pass
Interface:   SERVERS (or LAB)
Direction:   In
Protocol:    Any
Source:      <Omada controller IP>
Destination: MANAGEMENT net
Log:         No
Description: Allow Omada to manage MGMT VLAN

Without this rule, any "Block SERVERS to MANAGEMENT" rule will prevent the Omada controller from reaching the switches, causing them to appear disconnected in Omada even though they are physically reachable.

IOT Rules

Two rules in this order:

Rule 1 — Block IoT from all internal networks

Action:      Block
Interface:   IOT
Direction:   In
Protocol:    Any
Source:      IOT net
Destination: 10.0.0.0/8  (or your internal range)
Log:         Yes
Description: Block IOT to all internal

Use an alias if your internal networks span multiple RFC1918 ranges (10.x.x.x, 192.168.x.x, 172.16.x.x). Create the alias under Firewall → Aliases and reference it as the destination.

Rule 2 — Allow IoT internet access

Action:      Pass
Interface:   IOT
Direction:   In
Protocol:    Any
Source:      IOT net
Destination: any
Log:         No
Description: IOT internet access

GUEST Rules

Two rules in this order:

Rule 1 — Block guests from all internal networks

Action:      Block
Interface:   GUEST
Direction:   In
Protocol:    Any
Source:      GUEST net
Destination: 10.0.0.0/8
Log:         Yes
Description: Block GUEST to all internal

Rule 2 — Allow guest internet access

Action:      Pass
Interface:   GUEST
Direction:   In
Protocol:    Any
Source:      GUEST net
Destination: any
Log:         No
Description: GUEST internet access

Step 8 — Force DNS via NAT (Optional but Recommended)

Prevents clients from bypassing your DNS server by pointing at a public resolver directly (e.g. 8.8.8.8). Any DNS query not going to your resolver gets redirected.

Navigate to Firewall → NAT → Port Forward. Create one rule per VLAN:

The invert on destination means: match any destination that is NOT your DNS server. This redirects rogue DNS queries while leaving legitimate queries to your resolver untouched.

Omada Switch Configuration

Step 1 — Create Networks in Omada

Navigate to Settings → Wired Networks → Networks.

Create a network entry for each VLAN. The VLAN IDs must exactly match what you configured in OPNsense.

Step 2 — Create Switch Port Profiles

Navigate to Settings → Wired Networks → Switch Profile.

Port profiles define how a switch port handles VLAN traffic. Create one profile per VLAN for access ports, plus one trunk profile for uplinks.

Access Port Profiles (one per VLAN)

Used for end devices — servers, workstations, NAS, IoT devices.

Create one profile for each VLAN:

Trunk Profile (for uplink ports)

Used for ports connecting to OPNsense or between switches. Carries all VLANs tagged.

Why Management as native on trunk? Untagged frames that arrive on a trunk port (e.g. switch management traffic) need to land somewhere. Assigning management as native ensures switch-to-switch communication stays on the correct VLAN rather than defaulting to VLAN 1.

Critical: When migrating switches to a MANAGEMENT VLAN, verify that VLAN 10 is in the Tagged Networks list of your trunk profile before applying the management VLAN config to any switch. If VLAN 10 is missing from the trunk, the switch will be unreachable after migration even though it is physically connected.

Step 3 — Assign Profiles to Switch Ports

Navigate to Devices → [Switch] → Ports.

Click a port and assign the appropriate profile.

Example: Upstream Switch (connected to router)

Example: Downstream Switch

Trunk ports must be trunk on both ends. If port 1 on the downstream switch is set to TRUNK - ALL but the corresponding port on the upstream switch is set to an access profile, VLANs will not pass correctly.

Switch Migration Order

When migrating switches to a MANAGEMENT VLAN, always work upstream first:

1. Configure and verify the upstream switch (closest to OPNsense) before touching downstream switches
2. Confirm the upstream switch is reachable at its new MANAGEMENT VLAN IP before proceeding
3. Only then migrate downstream switches, one at a time

Migrating a downstream switch before its upstream is configured means tagged MANAGEMENT traffic cannot flow back to OPNsense, leaving the switch unreachable.

Verification

Once configuration is complete, verify each layer is working correctly.

DNS Resolution

From a client on each VLAN, confirm DNS resolves correctly:

# Should return an IP via your internal DNS resolver
dig example.com @<dns-server-ip>

# Internal hostname should resolve
dig server01.internal @<dns-server-ip>

Inter-VLAN Connectivity

Test that your firewall policy is enforced:

# From TRUSTED — should reach servers
ping 10.10.30.10

# From SERVERS — should NOT reach trusted workstations
ping 10.10.20.10   # expect: timeout

# From IOT — should NOT reach any internal host
ping 10.10.20.10   # expect: timeout
ping 10.10.30.10   # expect: timeout

# From any VLAN — internet should work
ping 8.8.8.8

DHCP Leases

Confirm devices are receiving IPs in the correct subnet:

ip addr show   # Linux
ipconfig       # Windows

Check active leases in OPNsense under Services → Dnsmasq → Leases — confirm each device's IP falls within its expected VLAN subnet.

Firewall Logs

Navigate to Firewall → Log Files → Live View in OPNsense. Generate some cross-VLAN traffic and confirm block rules are logging hits as expected.

Common Issues

Device received wrong subnet IP

The port profile on the switch does not match the intended VLAN. Check:

1. The port's assigned profile in Omada
2. That the profile's Native/Untagged network matches the intended VLAN
3. That the VLAN ID in the Omada network matches OPNsense exactly

No internet from a VLAN

The allow rule for that VLAN is missing or below a block rule that is matching first. Check rule order in Firewall → Rules → [Interface].

Can't reach OPNsense gateway from a VLAN

The VLAN interface IP is not configured. Check Interfaces → [VLAN] and confirm a static IPv4 address is set.

Cross-VLAN traffic that should be blocked is getting through

A block rule is missing or in the wrong position. Remember: first match wins. Block rules must be above any pass rules that would otherwise match the same traffic.

Trunk port not passing all VLANs

Either the trunk profile is missing a VLAN in Tagged Networks, or the OPNsense VLAN interface is not assigned/enabled. Check both ends of every trunk link.

Omada controller cannot reach switches after MANAGEMENT VLAN migration

The Omada controller is on a different VLAN (e.g. SERVERS/LAB) and a block rule is preventing it from reaching the MANAGEMENT VLAN. Add an explicit pass rule on the controller's VLAN interface allowing the controller IP to reach MANAGEMENT net, placed above any block rules. See the SERVERS Rules — Exception for Omada Controller section above.

Reference

• OPNsense VLAN Documentation
• OPNsense Firewall Rules
• OPNsense NAT
• OPNsense Dnsmasq
• TP-Link Omada VLAN Configuration
• TP-Link Omada Management VLAN Configuration