Prioritizing VoIP and Limiting Guest Wi‑Fi with pfSense Traffic Shaper

Problem: Guest Wi‑Fi Saturates the Link and Degrades VoIP

Many small offices run a separate wireless network for visitors. When guests stream video or download large files, the shared Internet uplink can become congested, causing noticeable jitter and dropped packets on VoIP calls. The goal is to keep the guest network usable but prevent it from starving latency‑sensitive traffic.

Thesis: pfSense’s Built‑In Limiter (ALTQ/HFSC) Can Enforce Bandwidth Caps and Prioritize Queues Without Extra Packages

The pfSense firewall includes a traffic shaper that works directly with the packet filter (pf). By defining limiters (queues) and binding them to firewall rules, you can set maximum bandwidth for specific subnets and assign priority levels to other traffic classes—all using the HFSC scheduler already present in the base system.

Understanding the Limiter and HFSC Scheduler

The Limiter interface creates one or more pipe objects (bandwidth ceilings) and queue objects (priority levels). HFSC separates traffic into hierarchical classes; each class can have a realtime (minimum latency) and an linkshare (bandwidth share) curve. For simple caps, you only need a pipe with a bandwidth limit and a queue that uses that pipe.

Key points:

• Pipe: Defines the maximum rate (e.g., 2 Mbps).
• Queue: Attached to a pipe; can be given a priority (low, normal, high).
• Rule binding: A firewall rule passes traffic through a specific queue, thereby enforcing the pipe’s limit.

Worked Example: Limit Guest Wi‑Fi to 2 Mbps Download, Keep LAN Unrestricted, Prioritize VoIP

Assume:

• LAN subnet: 192.168.1.0/24
• Guest Wi‑Fi subnet: 192.168.2.0/24
• VoIP server: 10.0.0.10 (or any SIP/RTP ports)

Step 1: Create the Pipes

1. Log in to the pfSense web GUI as an admin.
2. Navigate to Traffic Shaper → Limiter → Pipes.
3. Click Add.
• Name: guest_download_pipe
• Bandwidth: 2 Mbps (download direction)
• Bandwidth metric: Kbit/s or Mbit/s as preferred.
• Leave Delay blank (default).
4. Save.
5. Add a second pipe for VoIP priority (optional, but useful to guarantee minimal latency):
• Name: voip_priority_pipe
• Bandwidth: 1 Mbps (enough for typical voice codecs).
6. Save.

Step 2: Create the Queues

1. Go to Traffic Shaper → Limiter → Queues.
2. Add a queue for the guest pipe:
• Name: guest_queue
• Pipe: guest_download_pipe
• Weight: 1 (default).
• Priority: low (or leave default).
3. Save.
4. Add a queue for VoIP:
• Name: voip_queue
• Pipe: voip_priority_pipe
• Priority: high.
5. Save.

Step 3: Apply Queues via Firewall Rules

Rules are evaluated top‑to‑bottom; place more specific rules above generic ones.

1. Navigate to Firewall → Rules → LAN (or the interface where traffic enters).
2. Add a rule for VoIP traffic:
• Action: Pass
• Interface: LAN
• Address Family: IPv4
• Protocol: UDP/TCP (or specify SIP ports 5060/5061 and RTP range).
• Source: any (or your PBX subnet).
• Destination: 10.0.0.10/32 (VoIP server).
• Advanced Features → In/Out Pipe: Leave blank (we’ll use queue).
• Advanced Features → Queue: Choose voip_queue for both Upload queue and Download queue.
3. Save and apply changes.
4. Add a rule for the guest subnet:
• Action: Pass
• Interface: LAN (or the interface where guest APs connect).
• Source: 192.168.2.0/24
• Destination: any
• Advanced Features → Queue: Select guest_queue for both upload and download.
5. Save.
6. Ensure a final “default allow LAN to any” rule exists below these, without a queue, so LAN traffic not matching the VoIP or guest rules flows unrestricted.

Step 4: Verify the Shaper Is Working

Use the built‑in diagnostics; no external testing tools are required for basic validation.

1. From a host in the guest subnet, run a speed test (e.g., speedtest-cli or a web‑based test) and note the downstream speed. It should not consistently exceed ~2 Mbps.
2. From the pfSense console or via SSH (admin rights), run:

pfctl -s queues

3. Look for lines showing guest_queue and voip_queue with packet/byte counters increasing as traffic flows.
4. Alternatively, open Diagnostics → pfTop and observe the queue columns; guest traffic should appear in guest_queue.
5. To confirm the limiter is the limiting factor, temporarily disable the guest rule (or set its queue to none) and repeat the speed test; throughput should rise noticeably.

Trade‑Offs and Limitations

While the Limiter is powerful, consider these points:

• CPU overhead: HFSC queue processing adds per‑packet cost. On low‑end appliances (e.g., SG‑1100) with many concurrent queues, CPU usage can rise, potentially reducing overall throughput if the device is already near capacity.
• Rule ordering matters: If a generic “allow any” rule appears before the VoIP or guest rules, traffic will bypass the queues. Always verify placement.
• Latency for real‑time traffic: Setting the VoIP pipe too low can introduce jitter. Start with a modest guarantee (e.g., 512 kbps) and monitor call quality; increase only if needed.
• Interaction with other features: The shaper works alongside VPN, captive portal, and IDS, but encrypted traffic (e.g., HTTPS) cannot be inspected for application‑level shaping without SSL‑bump, which is outside the limiter’s scope.

Actionable Closing

To implement bandwidth control for guest Wi‑Fi while protecting VoIP:

1. Define pipes for the bandwidth ceiling you want (guest) and for any priority guarantees (VoIP).
2. Create queues bound to those pipes and assign appropriate priority levels.
3. Insert firewall rules that match the relevant subnets or ports and point them to the queues.
4. Validate with speed tests and pfctl -s queues or pfTop.
5. Monitor CPU usage under load; if the appliance shows sustained high utilization, consider simplifying the queue hierarchy or upgrading hardware.

By following these steps, you gain deterministic control over traffic distribution without installing additional packages, keeping the pfSense installation lean and manageable.