VLANs divide one physical network into separate Layer 2 domains

A VLAN tag lets a managed switch carry several isolated broadcast domains over shared physical infrastructure. OPNsense can assign each VLAN as an interface, give it an IP network and apply firewall policy to traffic that crosses between those networks.

The separation only works when the switch and endpoint configuration agree. A VLAN number typed into OPNsense does not automatically configure the switch, access point or hypervisor on the other side of the cable.

VLAN design changes the hardware path because traffic inside one VLAN can remain on the switch, while traffic between VLANs is routed by OPNsense when it is the gateway. That means a workstation copying to a server in the same VLAN may never touch the firewall, but the same copy across security zones can consume firewall and trunk capacity. Estimate the routed traffic matrix rather than adding every endpoint's link speed together.

The firewall-to-switch link is the core trunk

The trunk between OPNsense and the managed switch carries the VLANs that need to reach the firewall. Current OPNsense documentation recommends using tagged VLANs on this link and avoiding an untagged native VLAN where the switch allows it.

This tagged-only pattern reduces ambiguity around DHCP, router advertisements, CARP and other broadcasts. If the switch cannot operate without a native VLAN, the OPNsense guide suggests using a sacrificial VLAN that is not used elsewhere.

A managed switch is also part of the security boundary. Access ports should present the intended untagged network to ordinary endpoints, while trunks carry only the tagged networks that genuinely need to cross them. Wireless access points often need a trunk when multiple SSIDs map to different VLANs. Keeping a documented native/untagged policy and pruning unused VLANs reduces accidental exposure and makes troubleshooting far easier.

Access ports should be simple for ordinary endpoints

A desktop, printer or other non-VLAN-aware endpoint normally connects to an access port. The switch associates ingress traffic with one VLAN and sends egress frames to the device without requiring the endpoint to understand 802.1Q tags.

This keeps endpoint configuration simple and puts segmentation policy in the network infrastructure. Avoid exposing extra VLANs to ports that do not need them.

Access-point trunks are often intentionally mixed

Wireless access points frequently need an untagged management network plus tagged VLANs for additional SSIDs. That differs from the tagged-only firewall trunk, and OPNsense documentation explicitly calls out the distinction.

Follow the AP vendor's management-VLAN behavior. Treat the AP link as a purpose-built trunk and allow only the SSID VLANs that the device serves.

Inter-VLAN traffic is where firewall performance matters

Devices inside one VLAN can communicate directly through the switch. When a client in one VLAN talks to a server in another, the packet is routed by OPNsense and evaluated against firewall policy.

That means the sum of every access-port speed is not the right firewall sizing number. Estimate the traffic that actually crosses VLAN boundaries and the services that inspect it.

A 2.5GbE trunk can be enough until server traffic grows

For guest, IoT and ordinary client networks, routed demand may stay well below 2.5GbE. Add a fast NAS, virtualization cluster or backup VLAN and the inter-VLAN traffic can rise quickly.

Move to 10GbE when the traffic matrix justifies it, not because the VLAN count reached an arbitrary number. The network architecture calculator can model that transition.

VLAN pruning reduces accidental exposure

Only carry VLANs on trunks that need them. OPNsense documentation describes manual VLAN pruning as good practice because it limits where each broadcast domain exists and makes the configuration easier to reason about.

A trunk that allows every VLAN everywhere may work, but it increases the blast radius of mistakes and makes switch diagrams less useful during troubleshooting.

LAGG is optional, not a VLAN requirement

OPNsense can place VLANs directly on a physical interface or on top of a LAGG. The guide presents LACP as an optional abstraction that can add resilience or aggregate multiple physical links.

For a small installation, one reliable 10GbE trunk may be easier to maintain than a multi-link LAGG. Choose LAGG for a clear failure or capacity reason.

Do not create a bridge loop to imitate a switch

OPNsense warns against bridging multiple firewall ports to the same switch in place of a proper Layer 2 aggregation design. That can create a network loop.

Use the managed switch for Layer 2 switching and LACP for supported aggregation. The firewall should not become an accidental unmanaged switch.

Virtualized VLAN trunks need a clear ownership model

On Proxmox, VLAN tags can be handled by a VLAN-aware Linux bridge or passed as a trunk to the OPNsense guest, depending on the design. The key is to know where each tag is added, removed and filtered.

Avoid configuring the same VLAN logic in several layers without a reason. A simple ownership model is easier to test and recover.

Management access deserves its own failure plan

A management VLAN can improve separation, but it should not trap administrators outside the switch when OPNsense is down. Keep a documented local recovery path, console method or known access port.

The more segmentation you add, the more important it becomes to document which device is the gateway, where DHCP lives and which switch ports carry each VLAN.

A final VLAN hardware checklist

Confirm the switch is managed, the firewall trunk is intentional, AP trunks match vendor requirements, access ports expose only their assigned VLAN, inter-VLAN traffic fits the firewall link, and management remains reachable during maintenance.

Then test DHCP, DNS, routing and firewall policy from one client in every security zone. A topology is not complete until the failure cases are understood as well as the happy path.