Skip to main content
RunBook Academy

← All break/fix scenarios in OPNsense

advancedPerformance~25 min

Break/Fix: PF State Table Near Full

Reported symptoms

  • ●New outbound connections hang or time out
  • ●Established sessions drop at random
  • ●pfctl -si shows states at the configured maximum

Evidence

  • · pfctl -si: current entries: 200000/200000 (state table full)
  • · pfctl -ss | wc -l close to the configured maximum
  • · Firewall log: "src fault" or "state insert failed" entries
Diagnosis and resolutionclick to reveal

Root cause

The PF state table is sized too small for the current connection volume, or the table is filling with idle states from misbehaving clients (NAT keepalives, chatty services, scan traffic).

Remediation

1. Identify the current state count and the configured limit via pfctl -si. 2. Inspect the top sources with pfctl -ss | awk '{print $3}' | sort | uniq -c | sort -rn | head. 3. Either raise the limit (System → Settings → Firewall → Maximum states) or apply per-host connection limits (Firewall → Rules → Advanced → Max states). 4. Tune state timeouts for the dominant traffic pattern (lower for short flows, default for long flows).

Verification

State count stays below 80% of the configured maximum under load; new connections establish; syslog stops reporting "state insert failed".

Prevention

Size the state table for peak concurrent connections: a rough rule is 2–4× the number of active internal clients. Monitor pfctl -ss counts in your observability stack and alert at 70% of the configured maximum. Apply per-host limits to noisy services.

Scenario

You are operating an OPNsense edge under heavy traffic. The following symptoms appear:

  • New outbound connections hang or time out
  • Established sessions drop at random
  • pfctl -si shows states at the configured maximum

Available evidence:

  • pfctl -si: current entries: 200000/200000 (state table full)
  • pfctl -ss | wc -l close to the configured maximum
  • Firewall log: “src fault” or “state insert failed” entries

Your task

Determine the cause, recover, document, and validate.

Investigation

The investigation follows the discipline taught in Part XXXV:

  1. Form hypothesis, find evidence, test, validate.
  2. Use the available evidence above to bound the search.
  3. Reach one of the likely root causes.

Recovery procedure

(Do not reveal until you have reasoned through the problem.)

  1. Identify the failing component.
  2. Apply the remediation pathway.
  3. Validate with the verification step.
  4. Document the incident.

Remediation

  1. Identify the current state count and the configured limit via pfctl -si. 2. Inspect the top sources with pfctl -ss | awk '{print $3}' | sort | uniq -c | sort -rn | head. 3. Either raise the limit (System → Settings → Firewall → Maximum states) or apply per-host connection limits (Firewall → Rules → Advanced → Max states). 4. Tune state timeouts for the dominant traffic pattern (lower for short flows, default for long flows).

Verification

State count stays below 80% of the configured maximum under load; new connections establish; syslog stops reporting “state insert failed”.

Rollback

Revert the maximum-states change and remove per-host rules; expect the table to fill again at the original load.

Prevention

Size the state table for peak concurrent connections: a rough rule is 2–4× the number of active internal clients. Monitor pfctl -ss counts in your observability stack and alert at 70% of the configured maximum. Apply per-host limits to noisy services.