Skip to content

VLAN Basics in pfSense

How the Netgate 6100 MAX (running pfSense — see Netgate 6100 MAX Administration) handles VLANs, as the Layer 3 counterpart to the VLANs & Inter-VLAN Routing concepts already covered on the Cisco side. For the conceptual model behind these steps, see Routing and VLANs in pfSense.

What pfSense Does With VLANs

  • Creates logical subinterfaces on a physical NIC (or bond) tagged with VLAN IDs
  • Routes traffic between VLANs through firewall rules
  • Assigns IPs and handles DHCP per VLAN
  • Acts as the default gateway for each VLAN

This mirrors the SVI concept from VLANs & Inter-VLAN Routing — pfSense's per-VLAN interface plays the same role as a Cisco SVI, just configured through a GUI instead of interface Vlan10 / ip address.

Prerequisites

  • A physical NIC that supports VLAN tagging — most modern NICs do, including the Netgate 6100 MAX's onboard ports: four 2.5GbE LAN ports (igc0–igc3) and four WAN ports (ix0–ix3, 10G SFP+ and 1G combo)
  • A managed switch configured to trunk VLAN traffic to the pfSense port — see Connecting VLANs Across Multiple Switches for the Cisco-side trunk config that needs to match
  • Understanding of VLAN IDs (1–4094, usually 2–4094 for user VLANs — see VLANs & Inter-VLAN Routing)

Best practice: once a port carries tagged VLANs, don't also use the parent interface itself (e.g. igc1) as an untagged network — put everything on that port in tagged VLANs and configure the Cisco side as a pure 802.1Q trunk. Netgate's guidance is that the parent interface should exist only to host its VLANs; mixing tagged and untagged traffic on the same port can cause switch-side problems and forces use of the default VLAN on the trunk, which is best avoided.

Configuration Steps (High Level)

1. Create VLAN Interface

  • Go to Interfaces → Assignments, then the VLANs tab
  • Click Add
  • Select the parent physical interface (e.g. igc1)
  • Enter the VLAN Tag (e.g. 10 for Management, 20 for Guest)
  • Click Save

2. Assign VLAN to a Logical Interface

  • Go to Interfaces → Assignments
  • Select the VLAN just created from the Available Network Ports dropdown
  • Click Add — it appears as a new OPTx interface
  • Give it a friendly name (e.g. GUEST) when configuring it in step 3

3. Configure the Interface

  • Click the logical interface name
  • Check Enable interface
  • Set IPv4 Configuration Type to Static IPv4
  • Set an IPv4 address + subnet (e.g. 192.168.10.1/24)
  • Save & Apply
  • Then enable the DHCP server if needed — see DHCP Fundamentals for the underlying DORA process

4. Set Firewall Rules

  • Go to Firewall → Rules
  • Rules exist per interface, so each VLAN can have its own ruleset
  • Default: traffic between VLANs is blocked; you explicitly allow what crosses

This is the same default-deny philosophy already used in the Firewall Rules section of the Netgate admin page — allow specific known-good traffic, block everything else by default.

5. Verify

  • Status → Interfaces should show the new VLAN interface as up, with its IPv4 address
  • Connect a device to a switch access port in that VLAN and confirm it gets a DHCP lease (if enabled in step 3) and can ping the VLAN gateway (e.g. 192.168.10.1)

Then confirm the trunk to pfSense is actually carrying the VLAN. On the Cisco switch, from privileged EXEC:

show interfaces trunk

The VLAN should appear as both allowed and active on the trunk port toward pfSense. If it's missing, the switch-side trunk config doesn't match — see Connecting VLANs Across Multiple Switches. Catching a trunk mismatch here is much cheaper than discovering it in production.

Key Concept: Routing Between VLANs

VLANs are isolated by default. To let VLAN 10 talk to VLAN 20, you create a rule on the interface of the VLAN that initiates the traffic — rules are matched inbound, where traffic enters the firewall — so add a pass rule on the VLAN 10 interface tab; return traffic is handled automatically by the stateful firewall. pfSense won't infer it from the routing table alone. This mirrors the ACL-based isolation already used on the Cisco side in Access Control Lists, just enforced at the firewall instead of the switch.

This allows fine-grained designs: an equipment network fully isolated from guest Wi-Fi, but with specific, narrow communication paths to control systems — rather than an all-or-nothing choice between fully isolated and fully open.

Example VLAN Design

An example three-VLAN design (see VLANs & Inter-VLAN Routing for the general pattern):

  • VLAN 10 (Management) — infrastructure and control systems
  • VLAN 20 (Guest) — public/untrusted Wi-Fi
  • VLAN 30 (Video) — dedicated for high-bandwidth feeds

Each isolated by default at the pfSense firewall — your rules dictate exactly what's allowed to cross between them, rather than leaving it open by default and trying to block problems as they surface.