VLAN trunking on a single vNIC

A small OPNsense deployment has WAN, LAN, maybe a guest network and a server VLAN. The naive design gives each VLAN its own physical NIC. The right design gives the firewall one or two physical NICs (or vNICs) configured as 802.1Q trunks, with the VLANs created as sub-interfaces on top. This lesson covers how 802.1Q trunking works, how to configure it in OPNsense, the MTU implications, and the asymmetric trunk misconfiguration that is the single most common production bug.

How 802.1Q trunking works

An 802.1Q-tagged frame is a normal Ethernet frame with a four-byte VLAN tag inserted between the source MAC and the ethertype:

+----------+----------+----------+----------+----------+----------+
| Dest MAC | Src MAC  | 802.1Q   | Ethertype| Payload  | FCS
+----------+----------+----------+----------+----------+----------+
            |          4 bytes
            |          TPID (0x8100) + TCI (12 bits VLAN ID + 3 bits PCP)

The TPID 0x8100 marks the frame as 802.1Q-tagged. The TCI holds the 12-bit VLAN ID (0–4095) and 3 bits of priority code point (PCP, used for QoS). A trunk interface carries tagged frames; an access interface strips the tag and forwards the untagged frame to the host.

A switch port configured as a trunk sends tagged frames; the firewall’s NIC receives them and the kernel exposes each VLAN ID as a separate sub-interface.

$ tcpdump -nei igb0 -e 'vlan'

12:34:56.789012 aa:bb:cc:11:22:33 > ff:ff:ff:ff:ff:ff, ARP, Request who-has 192.0.2.1 tell 192.0.2.50, length 28
12:34:56.789345 aa:bb:cc:11:22:33 > 66:77:88:99:aa:bb, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP, Reply 192.0.2.1 is-at 66:77:88:99:aa:bb, length 28

Configuring a VLAN interface in OPNsense

OPNsense exposes VLANs as interfaces under Interfaces → Assignments → VLANs (the exact menu path varies across versions; the key is “create a VLAN on top of an existing interface”). The configuration takes:

• Parent interface: the NIC or vNIC that carries the trunk traffic. For most installations this is the LAN-side NIC (e.g. igb1).
• VLAN tag: the 802.1Q VLAN ID (1–4094).
• Description: a human-readable name.

The VLAN appears as a new interface (e.g. igb1_vlan10) and can be assigned like any other interface in Interfaces → Assignments.

On the switch side, the port the firewall connects to must be configured as a trunk with the appropriate VLANs allowed. The firewall will receive tagged frames for each VLAN it has configured; the kernel strips the tag and delivers the packet to the right sub-interface.

MTU: the 1504-byte frame

A tagged frame is 4 bytes longer than an untagged frame. If the underlying network has an MTU of 1500 (the standard Ethernet MTU), a 1500-byte payload inside a tagged frame is 1504 bytes on the wire. This matters for two cases:

1. Jumbo frames. If the operator configures jumbo frames (MTU 9000) on a path, every device on the path must support the larger MTU. A switch port configured for MTU 9000 but connected to a NIC whose driver caps at 1500 silently fragments or drops the larger frames.

2. MTU mismatch. A firewall with a sub-interface MTU of 1500 and a trunk port on a switch with MTU 9216 will work for most traffic (because most frames are < 1500 bytes anyway), but path MTU discovery issues appear for large transfers.

The safe default: leave MTU at 1500 unless the operator has a specific reason to raise it. If the operator raises MTU on the firewall, raise it on the switch and on every device on the path.

Parent interface selection

For most OPNsense deployments, the parent interface for the VLAN trunk is the LAN-side NIC. The WAN is typically on a separate physical NIC without VLANs (because the ISP hands you a single untagged link, and VLAN tagging on WAN only makes sense for ISPs that deliver services on VLAN tags like IPTV).

In a virtual environment (Lesson 34), the parent interface is the vNIC, and the Proxmox bridge carries the tagged frames to the physical NIC. The Proxmox bridge must be VLAN-aware (vlan_aware=1 in the bridge configuration), which it is by default in modern Proxmox versions.

A common production design:

Single physical NIC igb1 (or single vNIC vtnet1)
├── igb1_vlan10 → LAN (192.0.2.0/24)
├── igb1_vlan20 → Servers (198.51.100.0/24)
├── igb1_vlan30 → Guest (203.0.113.0/24)
└── igb1_vlan40 → Management (10.0.0.0/24)

Separate physical NIC igb0 → WAN (DHCP from ISP, no VLANs)

This design minimises NIC count and is the standard pattern for small-business and homelab firewalls.

Diagnosing trunk issues with tcpdump

The diagnostic workflow for “VLAN X is not working”:

tcpdump -nei igb0 vlan 10     # see every VLAN 10 frame
tcpdump -nei igb1_vlan10      # see what the kernel delivers to the VLAN 10 interface
tcpdump -nei igb1_vlan10 host 192.0.2.50   # see traffic for a specific host on VLAN 10

If the parent shows VLAN 10 traffic but the sub-interface shows nothing, the sub-interface is misconfigured or the kernel fails to bind it. If the parent shows nothing but the switch is sending traffic, the trunk on the switch is wrong.

Production patterns

Three patterns cover most deployments:

1. Single trunk vNIC + separate WAN NIC: the standard small-business design. One NIC carries all LAN-side VLANs; the other is WAN.
2. Two trunk vNICs + no WAN NIC: only used in MPLS / ISP environments where WAN is delivered on a tagged VLAN. Both NICs are trunks; one carries the ISP’s VLANs, the other carries the LAN-side VLANs.
3. Native-VLAN on the trunk: simplest on the firewall side but error-prone. Tag everything when possible.

Summary

• An 802.1Q trunk carries multiple VLANs across a single physical interface. Each VLAN appears as a sub-interface in the OS.
• In OPNsense, configure VLANs under Interfaces → Assignments → VLANs and assign them like any other interface.
• Asymmetric trunk configuration (firewall and switch have different VLAN lists) is the most common production bug.
• MTU: tagged frames are 4 bytes longer. Leave MTU at 1500 unless the operator has a specific reason to raise it.
• Use tcpdump -nei <parent> vlan <id> to see trunk traffic; use tcpdump -nei <vlan_subinterface> to see what the kernel delivers.