Skip to content

Wireless VLAN Build: pfSense, Catalyst & ZoneDirector

An end-to-end build putting wireless clients on their own firewalled VLAN: pfSense does all Layer 3 routing and DHCP, a Catalyst switch (2960-class in this example) stays pure Layer 2 and trunks to the firewall, and a ZoneDirector-managed AP tags wireless client traffic onto its own VLAN. The switch participates in every VLAN at Layer 2 but has exactly one Layer 3 address, on the management VLAN.

This composes several other pages into one working system — VLAN Basics in pfSense, Add a User VLAN, and ZoneDirector Administration cover the individual pieces in more depth.

1. Design & Addressing Plan

VLAN Name Subnet Purpose
10 MGMT 192.168.10.0/24 Infrastructure management (switch, controller, AP)
20 LAN 192.168.20.0/24 Wired clients
30 WIFI 192.168.30.0/24 Wireless client traffic (tagged by the AP)
Address Device Notes
192.168.10.1 pfSense VLAN 10 interface Gateway for MGMT
192.168.10.2 Switch SVI (interface Vlan10) Switch management, static
192.168.10.5 ZoneDirector Static, set on the device
192.168.10.10–11 MGMT DHCP pool The AP leases here; pool deliberately tiny
192.168.20.1 / 192.168.30.1 pfSense VLAN 20 / 30 interfaces Gateways; wireless clients lease 30.x

Conventions that keep this legible: subnet third octet matches the VLAN ID; gateway is always .1 (pfSense owns .1 on every subnet); infrastructure statics sit low (.2–.9); DHCP pools sit higher.

DHCP pool must exclude the gateway. A pool starting at .1 will eventually lease the interface's own address to a client — set ranges like 192.168.30.100–199.

2. Switch Configuration

Cisco IOS — global configuration mode (conf t):

Uplink trunk to pfSense, carrying all three VLANs:

interface GigabitEthernet0/1
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30

ZoneDirector port — plain access port on the management VLAN (the controller only ever carries control traffic):

interface FastEthernet0/11
 description Ruckus-ZD1200
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
 no shutdown

AP port — a trunk: the AP's own management traffic rides untagged on the native VLAN, wireless client traffic arrives tagged VLAN 30:

interface FastEthernet0/12
 description Ruckus-AP
 switchport mode trunk
 switchport trunk native vlan 10
 switchport trunk allowed vlan 10,30
 spanning-tree portfast trunk
 power inline auto

Management address and globals — one SVI only, on the management VLAN:

interface Vlan10
 ip address 192.168.10.2 255.255.255.0
interface Vlan1
 no ip address
 shutdown
ip default-gateway 192.168.10.1
spanning-tree portfast bpduguard default

Principles at work:

  • PortFast only on edge-device ports, never inter-switch links, always paired with BPDU Guard — spanning-tree portfast trunk is the variant for edge trunk ports like the AP's
  • One SVI, on MGMT. A Layer 2 switch is one host on the management VLAN; ip default-gateway is its single, whole-switch gateway setting, used only for traffic the switch itself originates. A leftover SVI on another VLAN can silently conflict with pfSense's gateway address there — audit with show ip interface brief | include Vlan
  • Audit before building on a used switch. Leftover NVRAM config (stray SVIs, an old ip default-gateway, power inline never on every port) produces mystery faults — see Configuration Management & Recovery for a clean-slate reset
  • Save with copy running-config startup-config after every verified change

3. pfSense

VLANs 10/20/30 defined on the trunk parent interface, each assigned, enabled, addressed .1/24, each with its own DHCP scope — the click-through is in VLAN Basics in pfSense and Add a User VLAN.

MGMT interface rules: allow DNS to the interface address; block MGMT → LAN; pass everything else (this gives the controller and AP internet access for firmware fetches while keeping them out of the wired LAN).

Managing the Lab from the WAN Side

When the firewall's WAN plugs into an existing upstream network and the management machine lives there:

  • WAN rule: pass IPv4 any-protocol, source = the management machine as a single host (give it a DHCP reservation upstream), destination any. Never open the WAN wide — scope to the one source address
  • Uncheck "Block private networks" on the WAN interface, since the upstream side is RFC 1918 space
  • Routing back: the upstream router knows nothing about the lab subnets. Either add static routes on it (durable — 192.168.10/20/30.0/24 via the firewall's WAN address) or per-session on the management machine:

On the management machine (macOS):

sudo route -n add -net 192.168.10.0/24 <firewall-WAN-ip>
sudo route -n add -net 192.168.20.0/24 <firewall-WAN-ip>
sudo route -n add -net 192.168.30.0/24 <firewall-WAN-ip>

Machine-side routes vanish on reboot; router static routes are the durable fix.

VPN clients eat routed traffic. A VPN client running on the management machine can capture traffic bound for internal subnets — pings fail, traceroutes go all-stars, and packet captures on the firewall stay empty. Many desktop VPN clients install a default route and offer no split-tunnel or allow-LAN option, and some rewrite the routing table again each time they reconnect. Disconnect the client before working on internal subnets, or re-add the routes after it connects. An empty capture on a correctly-ruled firewall points at the client machine, not the firewall.

4. ZoneDirector & AP

On the ZoneDirector (10.5.x sidebar UI):

  1. Log in (factory default admin/admin — change it immediately under Administer)
  2. System: set the country code (this sets legal channels/power), and a static Device IP on MGMT (192.168.10.5/24, gateway and DNS 192.168.10.1)
  3. Wireless LANs → Create (a WLAN, not a WLAN group): SSID, Standard Usage, WPA2/AES passphrase
  4. Advanced Options → Access VLAN: 30 — the critical field. Left at the default (1), client traffic leaves the AP untagged and lands on the AP port's native VLAN — the management network. Setting 30 makes the AP tag client frames so they ride the trunk to pfSense's WIFI interface
  5. Access Points: approve the AP when it appears; allow the firmware sync

The mental model: one cable, two traffic types. The AP's own IP lives on MGMT (untagged/native, leased from the tiny MGMT pool) and is used to talk to the controller; wireless clients are tagged VLAN 30 and lease 30.x. The controller carries only control traffic and never touches the wifi VLAN. AP↔controller discovery is same-subnet Layer 2 — it never crosses the firewall.

To serve an SSID on 5GHz only: Access Points → edit AP → Radio B/G/N (2.4GHz) → untick WLAN Service (per-SSID alternative: WLAN Groups bound to one radio).

If the AP Won't Join: SmartZone → Solo Reflash

An AP shipped with SmartZone firmware looks for a SmartZone controller and will never appear on a ZoneDirector (symptom: CTL LED flashing, AP absent from the controller). Fix: flash the AP's Solo (standalone) image, after which the ZD adopts it and pushes its own firmware — see firmware personalities for the image-type background.

Serve the Solo image over HTTP from the management machine:

On the management machine:

cd ~/Desktop && python3 -m http.server 8000

AP CLI (rkscli, via SSH — default login super / sp-admin):

fw set proto http
# host and port are SEPARATE fields — host:port in one field becomes a bogus hostname (RESOLVE_FAIL)
fw set host <management-machine-ip>
fw set port 8000
fw set control <solo-image-filename>
# bypass the version check — a SmartZone build refuses the Solo image otherwise ("Control file Parse Error")
fw set ignore-fw enable
fw update
# the image writes to the inactive slot; NOTHING takes effect until reboot
reboot

Verify the image's MD5 against the download page before serving it. Header-related error messages during the flash can be non-fatal — judge by whether the new version boots. After reboot the AP discovers the ZD, gets adopted, and takes the ZD's firmware (second reboot).

SSH to Ruckus APs from modern macOS needs legacy options, since the AP offers only ssh-rsa: 

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa super@<ap-ip>

5. WIFI VLAN Firewall Rules

Final working set on the WIFI interface, in order (rules evaluate top-down, first match wins — blocks must sit above the pass):

# Action Source Destination
1 Block WIFI subnets LAN subnets
2 Block WIFI subnets MGMT subnets
3 Pass WIFI subnets any

Result: wireless clients get internet but cannot reach management or the wired LAN. Remember a brand-new interface has no rules, which means block-all — "connected, no internet" on a fresh VLAN is almost always missing pass rules.

6. Troubleshooting Reference

Symptom Cause Fix
Mystery SVI / wrong addresses on the switch Leftover NVRAM config from a previous life no interface Vlan<x>; correct ip default-gateway; audit with show ip interface brief \| include Vlan
Port configured but shows disabled Explicit shutdown in the port config no shutdown; check show interfaces status
PoE device not powering power inline never on the port power inline auto; verify with show power inline
Firewall GUI reachable from WAN, nothing behind it WAN rule scoped to TCP/443 to the WAN address only Widen to any-protocol/any-destination, source still the single management host
Pings to lab subnets fail, captures empty VPN client on the management machine capturing routed traffic Disconnect the VPN or re-add routes after connecting (see section 3)
Upstream devices can't reach lab subnets Upstream router has no route to them Static routes via the firewall's WAN address
SSH to AP refused: no matching host key type ssh-rsa Modern OpenSSH rejects legacy ssh-rsa The legacy -o options in section 4
AP never appears on the ZD, CTL LED flashing AP running SmartZone firmware Solo reflash (section 4)
fw update timeout then RESOLVE_FAIL Port appended to the host field fw set host and fw set port separately
Wireless client "gets" the gateway address as its IP DHCP pool range includes .1 Exclude the interface address from the pool
Wifi connected, correct lease, no internet Fresh interface has no rules (= block all) Add the pass rule (section 5)

The diagnostic ladder that works: ping outward in dependency order — pfSense VLAN gateway → switch SVI (proves the switch's gateway) → controller → AP. Each answer validates one more link. pfSense Diagnostics → Packet Capture splits "not arriving" from "arriving but blocked"; firewall logs only record blocks by default, so no log entry at all means the traffic never reached the firewall.

7. Verification

  • show vlan brief / show interfaces trunk / show ip interface brief | include Vlan — all VLANs present, trunk carrying all three, single SVI
  • show power inline — AP drawing power (802.3af class)
  • pfSense DHCP leases — controller and AP on the MGMT pool
  • End-to-end proof: a client joins the SSID and leases from the WIFI subnet — one result that validates AP tagging, both trunks, the pfSense VLAN interface, and DHCP simultaneously
  • copy running-config startup-config after every verified change