Label pfSense packet captures with the NAT stage they observe

A capture and a firewall rule may legitimately show different addresses for the same flow.

Source facts

Netgate places inbound destination translation before interface filtering and outbound source translation before outbound floating rules. Its processing example also shows that WAN interface rules do not filter a connection merely because a LAN-originated packet later exits WAN. The capture hook sees packets before inbound processing and after outbound processing.

Source: Netgate — Ordering of NAT and Firewall Processing.

Applicability

This concerns the documented logical PF processing path in pfSense.

DSE recommendation

DSE recommends tracing one connection from ingress to egress with its original and translated address pairs written explicitly. Label evidence with interface, direction, and timestamp rather than attaching an unlabeled packet screenshot. When a rule counter stays unchanged, confirm that the rule belongs to a stage the packet actually traverses. Avoid adding duplicate WAN rules to compensate for a misunderstanding of LAN-originated filtering. Use one small evidence diagram with the original tuple, each translated tuple, and the observation point. Ask another engineer to predict the two captures from that diagram before seeing the results; reconcile any disagreement before changing a rule that may be functioning correctly.

Verification

Capture a narrowly filtered approved test flow on both relevant interfaces. Correlate ports and timestamps with the active NAT and filter entries. Check that the expected translation appears at the correct boundary and that the applicable ingress rule, rather than an unrelated egress-tab rule, makes the permission decision.

Official reference

Netgate — Ordering of NAT and Firewall Processing. Reviewed October 20, 2026.