Nothing generates more "please help" threads on r/Juniper and the Juniper community forums than SRX NAT. The symptom is always the same: the configuration looks right, the policy allows the traffic, but packets never arrive — or arrive untranslated. The good news is that SRX NAT failures follow a small number of patterns, and every one of them is visible in the session table. This guide walks the exact method used in the field, in the order that finds the fault fastest.

Sessions Are Your Source of Truth

On an SRX, trust the flow session, not the config. If traffic is flowing, it has a session; if there is no session, the packet died before flow creation. Look at the live translation:

show security flow session destination-prefix 203.0.113.10

The output shows in and out directions with original and translated addresses. If the NAT column shows the address you expected, NAT is working and the problem is routing or policy. If the session shows untranslated addresses, the NAT rule never matched. If there is no session at all, move to traceoptions at the end of this guide.

Step 1: Did a NAT Rule Even Match?

Every NAT rule keeps a hit counter. Zero hits means the rule scope (from-zone, to-zone, source-address, destination-address) never matched the packet:

show security nat source rule all
show security nat destination rule all
show security nat static rule all

Check the translation hits column. A common trap: a source NAT rule is defined for from-zone trust to-zone untrust, but the traffic actually hairpins from trust to a DMZ zone, so the rule never evaluates.

Step 2: Source NAT — The Interface and Pool Trap

For simple outbound NAT, most deployments should translate to the egress interface. If you forget the interface setting, sessions match the rule but no translation pool applies:

set security nat source rule-set OUTBOUND from zone trust
set security nat source rule-set OUTBOUND to zone untrust
set security nat source rule OUT rule match source-address 10.0.0.0/8
set security nat source rule OUT then translation-nat-type interface

If you use a pool, the pool addresses must be reachable from the upstream router — a translated source nobody can route back to is the classic "session shows NAT, replies never come" case. The SRX also needs a route for the return traffic to the real source; missing return routes silently kill flows even when NAT itself is perfect.

Step 3: Destination NAT and Proxy ARP

If your destination NAT (or static NAT) address lives on the same subnet as the SRX interface, the SRX will not answer ARP for it unless you configure proxy-arp. This is the single most common cause of "dest-NAT works from inside, dead from outside":

set security nat proxy-arp interface ge-0/0/0.0 address 203.0.113.10/32

Test from the upstream device with ping to the public address — if ARP fails, proxy-arp is your fix. If the public IP is a routed subnet delivered to the SRX, proxy-arp is not needed.

Step 4: Policies Match Pre-NAT Addresses

A frequent forum confusion: SRX security policies are evaluated against the original (pre-NAT) addresses in the packet, not the translated ones. If you wrote a permit rule for the translated address, it will never hit. Find which policy actually matched:

show security flow session destination-prefix 203.0.113.10 detail

Step 5: When No Session Appears — Flow Traceoptions

If packets never create a session, turn on flow debugging briefly (never leave it on in production):

set security flow traceoptions file flow.log size 5m
set security flow traceoptions flag basic-datapath
set security flow traceoptions packet-filter pf1 destination-prefix 203.0.113.10
commit

Then read show log flow.log. Lines such as "drop: NAT rule not matched", "policy deny", or "no route" tell you exactly which stage dropped the packet. Remove the traceoptions after diagnosis.

The 60-Second Checklist

  • show security flow session — is there a session at all?
  • NAT rule hit counters — did the rule match?
  • Proxy-arp configured for public IPs on the interface subnet?
  • Policy written against pre-NAT addresses?
  • Return route to the real source exists on the SRX?
  • Upstream device routes the translated pool back to the SRX?

Work the list top to bottom and you will find the break in minutes instead of hours. For the surrounding security configuration, our SRX zone, policy and NAT primer explains how zones, screens and NAT interact, the IPsec tunnel troubleshooting guide covers the VPN flavor of the same method, and show interfaces extensive helps when the physical path itself is suspect.