Why pfSense Speed Tests Are Slow and How to Diagnose Them

When a pfSense speed test shows slower download, upload, or latency than expected, the result does not always indicate a faulty broadband connection. The bottleneck may be between the test device and the router, inside pfSense, or upstream at the ISP. A reliable diagnosis requires controlled testing rather than one result from a single device.

What a Slow pfSense Speed Test Usually Looks Like

Common symptoms include download speeds below the subscribed service rate, upload performance that is disproportionately low, latency spikes during large transfers, or results that vary widely between tests. Some users also see normal speeds when connecting directly to a modem but slower performance when traffic passes through pfSense.

First, identify whether the problem affects download, upload, latency, or all three. Test at different times and record the device, connection type, selected server, and pfSense CPU usage. This information helps separate a broadband issue from a local routing or configuration problem.

Common Causes of Slow pfSense Speed Tests

Wi-Fi is limiting the result

A wireless client may be the main bottleneck even when pfSense is operating normally. Signal strength, channel congestion, client capabilities, distance, interference, and the wireless access point can reduce throughput. Run the same test from a wired device connected directly to a LAN port. If Ethernet is much faster, investigate Wi-Fi rather than changing WAN settings.

The pfSense hardware lacks processing capacity

Older or low-power hardware may struggle with high-speed fiber or cable broadband, especially when traffic inspection and encryption are enabled. During a test, check CPU utilization, memory use, and interface errors in the pfSense dashboard. A CPU that reaches sustained high usage can prevent the firewall from forwarding traffic at line rate.

Traffic inspection services are reducing throughput

Packages and services such as IDS or IPS, traffic shapers, proxy functions, VPN processing, and extensive logging can add processing overhead. Each service should be tested separately where practical. Temporarily disable one feature at a time during a controlled test, then restore it after the comparison. A large speed improvement identifies a configuration or capacity trade-off.

Incorrect traffic shaping is creating an artificial limit

Limiters, queues, and Smart Queue Management can intentionally cap bandwidth to control bufferbloat. If their rates are set below the available ISP bandwidth, a speed test will reflect those limits. Review limiter values, queue assignments, and floating firewall rules. Confirm that the test device is not assigned to a restricted alias or policy.

MTU or MSS settings are causing packet problems

Incorrect MTU or MSS values can cause fragmentation, retransmissions, or slow connections. This is particularly relevant when the WAN uses PPPoE, VLAN tagging, tunnels, or an upstream modem with a reduced frame size. Look for failed connections, retransmissions, or websites that load inconsistently. Test packet sizes without fragmentation and apply MSS clamping only when the network path requires it.

The ISP or access network is congested

Peak-hour congestion can reduce download or upload performance even when the local network is correctly configured. Compare wired results during busy and quiet periods, and test more than one reliable server. If every local device slows at similar times while pfSense resource usage remains normal, contact the ISP with timestamps and measured results.

The selected test server is not suitable

Speed tests depend on server capacity, geographic distance, routing, and the number of parallel connections. A distant or busy server may produce lower throughput and higher latency than a nearby server. Repeat the test with several reputable servers and compare the pattern instead of relying on one endpoint.

Duplex, cabling, or interface errors are affecting traffic

A damaged cable, poor connector, or negotiated link problem can reduce throughput or cause packet errors. Review the interface status in pfSense and check link speed, duplex mode, error counters, and dropped packets. Replace the cable and test another switch or LAN port if the negotiated rate is lower than expected.

How to Diagnose the Bottleneck

1. Connect one capable computer to pfSense with Ethernet and disconnect or pause other heavy traffic.
2. Run several tests against nearby servers and record download, upload, and latency results.
3. Repeat the tests from another wired device to rule out a client-specific issue.
4. Check pfSense CPU, memory, interface errors, firewall states, and active services during the test.
5. Compare results with selected inspection, VPN, shaping, or logging features temporarily disabled one at a time.
6. If possible, test the modem or ISP handoff directly, following the ISP's authentication and safety requirements.

A direct modem result that is fast while pfSense results are slow points toward hardware, configuration, or services on the firewall. Similar slow results in both setups suggest an ISP, modem, cabling, or access-network problem.

Optimization Recommendations for pfSense

Use wired testing as the baseline, keep pfSense and relevant packages updated, and confirm that the hardware can handle the WAN speed with the required services enabled. Remove unused packages, reduce unnecessary logging, and avoid enabling multiple overlapping traffic-management systems.

Review WAN settings for the correct interface type, VLAN configuration, MTU, and MSS behavior. Check that limiters and queues match the actual measured connection rate. If bufferbloat is the main concern, tune queue rates gradually and evaluate latency under load instead of optimizing only for the highest download score.

For VPN-heavy networks, use hardware with suitable CPU performance and confirm whether encryption acceleration is available and correctly configured. For high-speed fiber or cable broadband, verify that the network interface and switch ports negotiate at the required speed.

When to Contact the ISP

Contact the ISP when multiple wired devices show consistently low results, performance drops at predictable times, the modem reports errors, or direct testing at the service handoff remains slow. Provide test timestamps, server locations, wired results, latency measurements, and any relevant modem status information. Avoid claiming a fault based only on a wireless test or a single distant server.

Practical Checklist

• Test with Ethernet before evaluating Wi-Fi.
• Use multiple nearby speed-test servers.
• Record download, upload, and latency at different times.
• Monitor pfSense CPU, memory, interface speed, and error counters.
• Review shaping, VPN, IDS or IPS, proxy, and logging services.
• Verify MTU, MSS, VLAN, cabling, and duplex settings.
• Compare pfSense performance with an approved direct modem test.

A useful pfSense speed test is a repeatable measurement, not a single number. By changing one variable at a time, you can identify whether the limitation comes from Wi-Fi, pfSense processing, configuration, the test server, or the ISP connection.