# 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.

- Canonical URL: https://update.dsesecurity.com/updates/pfsense-state-table-nat-address-direction-diagnostics/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-15T13:33:31+00:00
- Modified: 2026-10-15T13:36:17+00:00
- Last reviewed by DSE: 2026-10-15
- Resource type: Guide
- DSE priority: Information
- Topics: IT, Networks & Infrastructure
- Reading time: 2 minutes

## 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.

## Article

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](https://docs.netgate.com/pfsense/en/latest/monitoring/status/firewall-states-gui.html).

## 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](https://docs.netgate.com/pfsense/en/latest/monitoring/status/firewall-states-gui.html). Reviewed October 15, 2026.

## Primary reference

- Name: Netgate — Viewing firewall states
- Authority: docs.netgate.com
- URL: https://docs.netgate.com/pfsense/en/latest/monitoring/status/firewall-states-gui.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Read both NAT addresses and both directions in the pfSense state table,” DSE Security, https://update.dsesecurity.com/updates/pfsense-state-table-nat-address-direction-diagnostics/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.