Read both NAT addresses and both directions in the pfSense state table

The state table can distinguish a translated connection from one that has not received a reply.

Resilient network core with engineered blue and gold data paths.
DSE visual intelligenceNetworks & infrastructureGuide · 2 min read
Executive summary

What you need to know

The state table can distinguish a translated connection from one that has not received a reply.

Potentially affected

This concerns Diagnostics > States in pfSense. State entries describe traffic observed by the firewall; they do not alone prove where a packet was lost or why a remote application failed.

DSE recommendation

DSE recommends recording the expected client, destination, port, and NAT translation before changing rules.

The state table can distinguish a translated connection from one that has not received a reply.

Source facts

Netgate’s state-table guide explains that pfSense displays original and translated addresses when NAT applies. The State column has two values separated by a colon, representing the source and destination sides. ESTABLISHED:ESTABLISHED describes established two-way TCP tracking, while SYN_SENT:CLOSED indicates a SYN without a response observed from the far side. For connectionless traffic, SINGLE:NO_TRAFFIC similarly indicates no matching response observed. The GUI can filter entries by a simple text expression, and an IP or subnet search also exposes a state-removal action.

Source: Netgate — Viewing firewall states.

Applicability

This concerns Diagnostics > States in pfSense. State entries describe traffic observed by the firewall; they do not alone prove where a packet was lost or why a remote application failed.

DSE recommendation

DSE recommends recording the expected client, destination, port, and NAT translation before changing rules. Use a narrow filter to inspect the relevant connection and compare both sides of the entry. Preserve a safe diagnostic snapshot with sensitive addresses handled appropriately. Distinguish a missing response from an application error after establishment. Treat the state-removal control as a separate disruptive action requiring a defined target and purpose, not a routine step for viewing a connection. Correlate uncertain results with approved packet captures or endpoint evidence.

Verification

Generate one approved test connection and inspect its original and translated addresses. Compare a successful exchange with an intentionally unavailable test destination. Confirm the filter matches the expected entries and avoid removing unrelated states while collecting evidence.

Official reference

Netgate — Viewing firewall states. Reviewed October 15, 2026.

Primary reference

Review the official source

Netgate — Viewing firewall states · Verified October 15, 2026

Open official reference ↗
Plan the next step

Need help applying this guidance safely?

DSE can help confirm applicability, protect service continuity, and validate the result across physical security and IT systems.

Talk with DSE