pfSense State Table Exhaustion Diagnostic Guide

New connections fail while existing flows stay up, logs show pf state-table-full and Status > System > States is at the limit. A compact diagnostic flow maps symptoms to causes, ordered checks, and fixes tied to findings with escalation criteria.

New connections fail while existing flows stay up

The classic signature of pf state table exhaustion in pfSense is intermittent connection failures for new traffic while already established sessions continue to work. The System log shows kernel messages from pf about the state table being full and Status > System > States shows current states at or near the configured maximum. That is the condition to treat first, not a generic performance issue.

Recognizable condition

Status > System > States reports current states close to maximum under load.
System Log shows pf state-table-full messages correlated with failure times.
Users report timeouts on new web, VPN or game connections; existing SSH or VoIP calls persist.

Cause / diagnostic map

Observation in states	Likely cause	Clue
One LAN host dominates the list	P2P/torrent client or large backup job	High count per source IP, many short-lived TCP states
Many short-lived WAN states from diverse sources	Internet scan or flood	High inbound attempts on closed ports
UDP states linger after flows end	Long UDP timeouts for VoIP, DNS	UDP states accumulate, little traffic
States hit limit on small VM/cloud image	Undersized defaults for hardware	Limit is low relative to RAM
Heavy inbound UDP churn from internal host	Open resolver or amplifier inside network	Destination port 53 or other service, many sources

Ordered checks

Status > System > States. Note current vs maximum. Check under normal and peak load.
System Log for pf messages. Look for state-table-full and timing. Correlate with recent rule, NAT or client changes.
Diagnostics > States or pfTop. Rank top sources and destinations by state count. Identify noisy host or port.
Console or SSH shell pfctl -si. Run as an administrator from console option 8 or SSH. This shows live counters and the effective state limit reported by the kernel. Compare to GUI.
```
pfctl -si
```
Risk: shell access is privileged. Audit access and restrict to authorized admins.
Correlate spike times with firewall changes, scheduled backups, or new devices.

Fixes tied to findings

Single noisy host

Add per-rule limits on the LAN rule that permits the host. In Firewall > Rules, edit the rule and set Advanced > State options: max states, max source nodes, max source states, max source connections per time period. Isolate the host if the behavior is unauthorized.

Scans / floods

Tighten WAN rules. Block unwanted inbound, enable basic anti-lockout only where needed, and consider upstream filtering. Do not use no-state rules as a workaround; it removes connection tracking and protection.

Lingering UDP states

Lower State Timeout on the specific rule for VoIP or DNS. Use rule-specific timeouts rather than global changes.

Genuine load growth

Raise Firewall Maximum States under System > Advanced > Firewall & NAT only within RAM headroom. Each state consumes kernel memory. Verify free memory first; raising the limit without headroom risks kernel memory exhaustion and instability.

After any change, reset states via Diagnostics > States > Reset States. This causes a brief session blip and drops existing VPN, VoIP and SSH sessions. Schedule during a maintenance window.

Verify the change

Re-open Status > System > States and confirm current states stay well below maximum under peak load.
Run pfctl -si again and confirm entries and limit match GUI.
Reboot and confirm the raised limit persists and appears in the exported configuration XML via Diagnostics > Backup & Restore.
Check free RAM remains with headroom after the change.

Limitations: exact default state limits vary by hardware model and release. Do not assume a single number applies to your install. Some pf versions include adaptive timeout behavior that can drop states before the hard limit; if symptoms appear below the configured limit, check pf tunables for your version.

Escalation criteria

States return to the limit soon after tuning.
Kernel memory pressure or out-of-memory symptoms appear.
Sustained legitimate load exceeds what the hardware can hold even at a raised limit.
The appliance or VM cannot be given more RAM.

In those cases move to larger hardware, engage Netgate support, or add upstream filtering and per-VLAN limits.

Practical engineering decision

Size the state limit to measured traffic and available RAM rather than setting the largest possible value. Record the chosen global and per-rule limits in the config export so tuning survives reinstalls and is reviewable in change management. The pf mechanics are shared across pfSense CE and pfSense Plus; menu labels and bundled tooling differ slightly between releases, so the same diagnostic flow applies to both editions.

pfSense State Table Exhaustion: Diagnose and Contain pf States Safely