The address the far end
actually saw.
Half of "the firewall rule is right and it still does not work" is translation. PathMRI models the NAT on the path from thirteen sources, and keeps what the configuration declares rigorously apart from what the device was observed doing.
Two different kinds of truth
Declared
What the configuration says will happen.
- ·Object and twice NAT on ASA; the separate NAT rulebase on PAN-OS, with translated port and post-NAT zone.
- ·VIPs and DNAT on FortiGate; port forwards, 1:1 and outbound modes on pfSense.
- ·Object and manual NAT across all three FTD sections; positional precedence on Check Point.
- ·Cloud egress derived from the route table — a real longest-prefix match, not an assumption.
Observed
What the device was actually doing.
- →
show xlateon ASA, the session monitor on FortiGate, the session table on PAN-OS and SRX. - →
pfctl -sson pfSense, conntrack on VyOS, Docker and Kubernetes. - →The source address the destination really received, reported beside the one you dialled.
- →Where a source is only declared and never observed, it says so rather than implying a measurement.
Why it decides the answer
The next firewall sees a different packet
A source translated to a dynamic pool does not arrive as the client's own address. A downstream policy evaluated against the wrong source answers allow while the device drops it.
Published ports are NAT too
Docker's published-port DNAT and bridge masquerade, and Kubernetes ClusterIP, NodePort and LoadBalancer translation, are modelled with the same contract every appliance gets — gated on the network driver, because host, macvlan and ipvlan translate nothing.
NAT before policy, where the vendor does it
FTD matches the real post-NAT destination, so the translation is resolved first. PAN-OS matches pre-NAT addresses with the post-NAT zone. The order is the vendor's, not a convention.