Routing and VLANs in pfSense¶
How the basic pieces connect in pfSense — the conceptual model behind the step-by-step clicks in VLAN Basics in pfSense, illustrated with an example topology.
Interfaces Are the Core Building Block¶
The core idea in pfSense is the interface. Everything — routing, firewalling, DHCP — hangs off interfaces. A physical NIC can be one interface, or it can carry several VLANs, each of which becomes its own logical interface. Once a VLAN is assigned as an interface, pfSense treats it exactly like a physical port: it gets its own IP address (which becomes the gateway for that network), its own DHCP scope, and its own firewall rules.
The flow when setting up VLANs:
- Create the VLAN (tag number + parent NIC) under Interfaces → Assignments → VLANs tab
- Assign it as a new interface, enable it, and give it a static IP such as
10.10.20.1/24— that IP is the default gateway for every device in that VLAN - Set up DHCP on it if wanted
- Write firewall rules to control what it can reach
This is the same sequence VLAN Basics in pfSense walks through screen-by-screen.
Routing Between VLANs¶
Routing between VLANs is automatic in one sense: because pfSense has an interface in each VLAN, all those networks are directly connected, so it knows how to route between them without any static routes. Whether traffic is allowed to flow is a separate question — that's the firewall.
A key pfSense quirk: rules are applied on the interface where traffic enters pfSense, and by default new interfaces have no rules — which means all traffic is blocked. A fresh VLAN cannot reach anything until pass rules are added on its tab. This is the same default-deny philosophy already covered in VLAN Basics in pfSense and on the Cisco side in Access Control Lists — just enforced per-interface here rather than via a named ACL.
The Switch Does the Breakout¶
pfSense does the tagging, but the cable between pfSense and the switch must be a trunk port carrying all the VLAN tags, and the switch then breaks them out to access ports for end devices. This is where Cisco switch configuration meets pfSense — the trunk and access port settings on the switch have to match the VLAN tags defined in pfSense. See Connecting VLANs Across Multiple Switches for the Cisco-side trunk config that needs to agree with what's defined here.
Example Topology¶
One physical LAN NIC carries all three tagged VLANs over a single trunk cable. The switch strips tags at each access port, so end devices never see VLANs at all.
Reading the Diagram¶
Top to bottom: the WAN interface faces the internet; the three VLAN interfaces all live on a single physical LAN NIC on the pfSense box, distinguished only by their tag numbers; one cable (the trunk) carries all three tagged networks to the switch; and the switch strips the tags at each access port so end devices never see VLANs at all — a lighting desk plugged into a VLAN 30 access port just thinks it's on a normal network with 10.10.30.1 as its gateway.
Since pfSense sits at the junction of all three networks, it's automatically the inter-VLAN router and the firewall between them. If the management laptop should reach the lighting desk but not the other way around, that's just a pass rule on the VLAN 10 interface with no matching rule on VLAN 30. This is how Dante traffic stays isolated from lighting while one console can still see everything.
Worth Knowing Before Trying It¶
- pfSense also needs an outbound NAT and DNS story for VLANs that should reach the internet — automatic outbound NAT usually handles this without any manual changes. See NAT & Private IP Ranges for the underlying concept.
- Multicast-heavy protocols like Dante and sACN generally should not be routed between VLANs anyway — keeping them contained per-VLAN is a feature, not a limitation.