If you are planning a pfSense + UniFi VLAN setup, the goal is not a clever diagram. The goal is stable day-to-day operations with clear policy boundaries and usable incident visibility.
I keep returning to one reference pattern because it performs consistently in real environments:
WAN -> Netgate/pfSense -> UniFi gateway bridge -> UniFi switching -> APs, cameras, clients
It is not flashy. It is stable, observable, and maintainable when documented correctly.
This is not presented as any one client network. It is a practical production baseline used to scope and validate SMB implementations.
This article walks through that example in plain language first, then in technical detail.
If you are planning a small or midsize environment, this is a strong baseline before adding complexity.
If you want this deployed and handed over cleanly, start with Networking Services or submit a brief.
pfSense + UniFi setup in one sentence
Use pfSense as the policy brain, UniFi as the access and switching fabric, segment everything meaningful with VLANs, and log enough to investigate incidents without drowning in noise.
Diagram (logical)
INTERNET / ISP
|
[ WAN ]
|
+------------------------------------------------+
| NETGATE / pfSENSE |
| Firewall | NAT | Inter-VLAN ACL | VPN | IDS |
+--------------------------+---------------------+
|
802.1Q TRUNK (10,20,30,40,50,99)
|
+------------------------------------------------+
| UNIFI UDB (UPSTREAM HANDOFF) |
| Passes tagged VLANs into switching fabric |
+--------------------------+---------------------+
|
+--------------------+--------------------+
| |
+------+-------+ +------+-------+
| UNIFI SW1 | | UNIFI SW2 |
+------+-------+ +------+-------+
| |
+-----------+------------+ +-----------+------------+
| | | |
+-------+------+ +-------+------+ +------+--------+ +-------+------+
| APs (Trunk) | | Cameras V30 | | Endpoints V10 | | Mgmt V99 |
| SSID->V20/40 | | IoT Segment | | Staff Devices | | Infra/Admin |
+--------------+ +--------------+ +---------------+ +--------------+
VLAN map (example):
V10 = Staff LAN V40 = Guest WiFi (internet only)
V20 = Staff WiFi V50 = Voice (optional)
V30 = Cameras / IoT V99 = Management (restricted)
Logging / telemetry path:
pfSense firewall + DHCP + DNS ---> log sink / SIEM
UniFi events + device changes ---> same time-synced log sinkWhy this pattern works
Three reasons:
-
Clear role separation
pfSense handles security policy and routing logic. UniFi handles distribution and access ergonomics. -
Controlled blast radius
VLAN separation keeps a compromise in one zone from becoming a whole-network incident. -
Operational legibility
A new operator can read the network quickly: where traffic starts, where it is allowed, and where it is denied.
Layer-by-layer design
1) Edge and firewall: Netgate/pfSense
In this design, pfSense is where I anchor:
- ingress and egress policy
- NAT behavior
- inter-VLAN rules
- VPN entry points
- IDS/IPS strategy (where appropriate)
- DNS/IP reputation filtering
The rule: deny by default between sensitive segments, then add explicit allow rules by service and direction.
For non-specialists: think of pfSense as the building security desk. Nobody goes anywhere without being on the list.
1.1) Threat detection and blocking stack
I typically run Suricata, pfBlockerNG, and Pi-hole together:
- Suricata for IDS/IPS visibility and signature-based detection
- pfBlockerNG for DNSBL, IP reputation feeds, and noisy-source suppression
- Pi-hole for internal DNS policy, ad/tracker filtering, and per-client query visibility
This combo is strong when tuned and noisy when not tuned. Practical approach:
- start with IDS (alert-only), then move selected interfaces/policies to IPS
- tune for environment reality before enforcing drop actions
- suppress known-safe internal patterns to reduce alert fatigue
- keep rule updates scheduled and logged
- review block logs weekly so controls stay useful
Typical DNS design choices:
- pfSense resolver forwards selected VLAN DNS queries to Pi-hole
- Pi-hole applies internal block policies and forwards upstream securely
- management VLAN gets full DNS visibility; guest/camera VLANs stay locked down
For non-specialists: Suricata is the intrusion sensor, pfBlockerNG is the known-bad bouncer list, and Pi-hole is the DNS gatekeeper.
2) Distribution and access: UniFi
UniFi gives predictable switch/AP management and clean topology visibility.
Core practice:
- trunk VLANs upstream from pfSense
- tag VLANs on uplinks and AP ports
- keep edge ports as strict access where possible
- reserve management interfaces for VLAN 99 only
For non-specialists: UniFi is the wiring and door system. pfSense decides who is allowed through each door.
3) VLAN strategy
I use functional segmentation, not decorative segmentation.
Minimum practical split:
- staff trusted devices
- wireless staff
- cameras/IoT
- guest
- management
If a segment cannot be described in one sentence, it is usually overdesigned.
Logging and observability (the part teams skip)
Most outages are harder to solve because logging was “future work.”
Baseline I recommend for this architecture:
- pfSense firewall logs retained and forwarded
- Suricata alerts + drops retained with interface context
- pfBlockerNG DNSBL/IP block events retained
- Pi-hole query logs (with retention limits) for DNS-level investigations
- DHCP/DNS query visibility for incident context
- UniFi controller event logs preserved
- camera VLAN egress monitoring (unexpected destinations stand out fast)
- NTP synchronized everywhere (time drift ruins investigations)
If you only do one thing: centralize logs with consistent timestamps.
For non-specialists: logs are your flight recorder. You never miss them until you need them.
Practical policy examples
- Guest VLAN -> internet only, no RFC1918 east-west access
- Camera VLAN -> NVR and approved update endpoints only
- Management VLAN -> admin jump-hosts only
- Staff VLAN -> controlled access to shared services, not blanket trust
Small, explicit rules beat broad “allow all internal” shortcuts every time.
Failure modes this design prevents
- Compromised camera laterally reaching business systems
- Guest WiFi users discovering internal admin panels
- “Flat network” malware spread through SMB broadcast domains
- No traceability during incident response
Nothing prevents every failure. The point is to shrink impact and shorten recovery.
Cost and complexity reality
This architecture is not enterprise theater. It is SMB-realistic.
- one strong firewall decision point
- one switching ecosystem
- clear segmentation map
- disciplined logging
That is enough for most organizations to move from fragile to resilient.
What to document at handover
If I were handing this design to another operator tomorrow, they should receive:
- logical and physical diagrams
- VLAN + subnet table
- firewall policy summary by source/destination/service
- switch/AP port-profile map
- logging destinations and retention windows
- break-glass access process
If those are missing, the network is not truly transferred.
Final note
Good network architecture should feel quiet after go-live.
No drama, no mystery, no heroics. Just predictable behavior, clean boundaries, and enough observability to trust your own environment.
For adjacent design guidance, see VLAN segmentation that survives turnover and Network documentation is part of the deliverable.