Network address translation on an SRX firewall becomes much easier to troubleshoot when each NAT type has a clear purpose and the Junos processing order is understood. Source NAT changes the source identity of a connection, destination NAT changes where a connection is sent, and static NAT creates a persistent one-to-one mapping that can work in both directions. The current Juniper JNCIA-SEC JN0-232 objectives explicitly cover all three, while Juniper JNCIS-SEC JN0-336 builds on the same packet-flow reasoning in more advanced security scenarios.
The common mistake is to treat NAT as a separate feature that happens “somewhere before the firewall policy.” Junos applies different translation types at different points in first-packet processing. That means routing and policy can see translated information in some cases and original information in others. A correct mental model prevents hours of rule changes that never address the real mismatch.
Source NAT changes the identity presented to the destination
Source NAT is commonly used when private addresses initiate sessions toward networks that should see a translated source. The translation can use an interface address or an address pool, depending on the design. The policy decision still needs to authorize the session; translation does not grant access by itself.
A source NAT rule set uses match conditions to decide which flows are eligible and then applies a translation action. The design should make the rule boundaries obvious. A rule intended for user internet access should not accidentally match server-to-server traffic or management flows simply because the address ranges overlap.
Pool capacity and port usage matter in high-volume designs. Many internal sessions can share a smaller translated address space through port translation, but the available ports and platform limits are still finite. Troubleshooting intermittent failures therefore includes session scale and resource exhaustion, not only syntax.
Destination NAT changes where inbound traffic is delivered
Destination NAT is used when traffic sent to one address must be redirected to a different destination. A public service address mapped to an internal server is a common example. The important Junos detail is that destination translation happens before the route and security-policy lookup for the first packet.
That order affects both routing and policy reasoning. After destination NAT, the firewall determines how to reach the translated destination. The resulting route identifies the egress context, and the security policy must authorize the flow in the appropriate zone path. A policy written around the wrong destination object can therefore fail even when the destination NAT rule itself is matching.
Engineers should confirm both halves of the design: the translation exists and the translated destination is actually reachable through the expected zone. A hit counter on a NAT rule is not proof that the application can complete the session.
Static NAT creates a persistent mapping
Static NAT maps one address or prefix to another with a fixed relationship. It is useful when a host needs a consistent translated identity and when bidirectional initiation is part of the design. Junos also gives static NAT higher processing precedence than destination NAT when both could match the first packet.
The bidirectional property can surprise engineers who think only about inbound publication. Reverse traffic can use the corresponding mapping, and reverse static-NAT processing also has a defined place later in first-packet handling. This makes static NAT different from simply creating matching source and destination rules.
Because static mappings can affect routing and policy interpretation, overlap should be designed carefully. Broad prefixes, reused address space, and multiple translations can create ambiguous intent even when the configuration commits successfully.
Junos NAT order is the key troubleshooting model
For the first packet of a flow, current Junos documentation describes the processing sequence as static NAT, then destination NAT, then route lookup, then security policy lookup, then reverse mapping of static NAT, and finally source NAT. That order explains many situations that look contradictory when NAT is treated as one single stage.
Static and destination NAT happen before routing because they can change where the packet is going. Routing then determines the egress context needed for security policy. Source NAT occurs later because changing the source normally does not determine the destination route. Reverse static mapping has its own position and can take precedence over source NAT.
Memorizing the sequence is less useful than understanding why it exists. When an inbound packet is destination-translated, ask what destination the route lookup sees. When an outbound packet is source-translated, ask what source the policy saw before that translation. That reasoning leads directly to the right object and counter.
NAT rules and security policies answer different questions
A NAT rule asks whether an address should be translated. A security policy asks whether the session should be allowed. Both can match the same traffic, but they solve different problems and use different configuration hierarchies. Translation cannot substitute for authorization, and a permit policy does not create a translation automatically.
This separation is especially important during troubleshooting. A NAT rule counter may increase while the session is denied by policy. Conversely, a policy may permit a flow that never reaches the expected server because translation selected the wrong pool or mapping. Inspect the evidence at each stage instead of assuming one successful counter proves the whole path.
The distinction also keeps policy intent readable. Address translation often exists for topology or addressing reasons, while security policy should describe the actual allowed relationship between zones, applications, and protected resources.
Rule-set scope controls which flows can match
Source, destination, and static NAT use rule sets with match criteria that define where they apply. Engineers should pay close attention to interface, zone, routing-instance, and address context supported for the particular NAT type. Not every match condition is available at every processing stage because destination and static NAT run before the route lookup has established some later context.
Within a rule set, specificity and order should make the expected winner obvious. Broad “catch-all” translations placed ahead of exceptions can capture traffic unexpectedly. The best troubleshooting question is not “Is there a rule for this?” but “Which rule set is selected and which rule inside it matches first?”
Readable names and narrow scopes reduce ambiguity. A rule called “internet-source-nat-users” is easier to validate than a generic rule named “nat1,” especially months after the original deployment.
Use sessions and counters to prove each stage
Operational verification should move from rule counters to session state. NAT counters can show whether a rule is matching. Session output can show original and translated endpoints, the policy involved, interfaces, and other flow context. Route lookups confirm where translated destinations are expected to go.
If the rule never increments, check its match context. If it increments but no session forms, inspect the policy and route. If a session forms but the application fails, investigate return routing, upstream filtering, server behavior, or application-layer issues. This stepwise approach prevents NAT configuration from becoming the default suspect for every connectivity problem.
The underlying concepts in network address translation remain useful, but SRX troubleshooting requires the platform-specific processing sequence rather than a generic inside/outside model.
Return-path testing is especially important for published services. A successful SYN reaching the translated server proves only the forward half of the path. The server must return traffic toward the same stateful firewall path, and upstream routing must deliver the translated response consistently. Packet captures on both sides of the firewall can show whether the return packet is missing, entering through a different device, or being translated in an unexpected way.
DNS can add another layer of confusion. A hostname may resolve to a public address for external clients and to an internal address for local clients. That split behavior can be intentional, but it changes which NAT path should exist. Troubleshooting should begin with the address the client actually used, not the address an engineer expected it to use.
Design for asymmetric paths and operational clarity
Stateful firewalls expect traffic to fit the session state they create. Complex routing, multiple firewalls, load balancing, and asymmetric return paths can therefore break a design that looks correct when only the outbound packet is traced. NAT adds another layer because the return packet must correspond to the translated session state.
Clustered firewalls, multiple internet links, or overlapping private address spaces deserve explicit path diagrams. Engineers should document original source and destination, translated source and destination, ingress and egress zones, policy name, route, and expected return path. That small amount of discipline makes packet captures and session output far easier to interpret.
Junos operational work also becomes faster when configuration and command modes are familiar. The Junos CLI structure helps engineers move cleanly between NAT configuration, route verification, policy inspection, and live session troubleshooting.
Choose the NAT type that expresses the real requirement
Source NAT is appropriate when the key requirement is how an initiating source is represented. Destination NAT is appropriate when traffic sent to one destination must be redirected. Static NAT is appropriate when a fixed mapping and reverse relationship are required. Designs become harder to reason about when one type is stretched to imitate another without a clear operational reason.
The security track within Juniper certifications expects practitioners to connect NAT concepts to packet processing and troubleshooting. The durable skill is being able to trace the first packet in order: determine which translation can happen, identify the route and zones that result, find the policy decision, determine any later translation, and then verify the session state that carries the return traffic.