ACL Order Before and After NAT

Introduction to Segmentation Policy and NAT

Overview of Intended Segmentation Policy

The intended segmentation policy defines who may talk to whom using identity objects (security zones, address groups, applications, user tags). Example:

allow from zone Trust to zone DMZ application https
deny  from any    to any

The management system renders this into a rule set that is applied by the enforcement point (stateful firewall). The observed state is what actually occurs on the wire (logs, captures, flow tables).

A common source of drift is the difference between pre‑NAT and post‑NAT evaluation order. Assuming a single monolithic policy can cause operators to miss that a packet may be judged twice—once before address translation and once after—leading to forward‑direction allowance but reverse‑direction denial, even though the intended policy permits both directions.

Understanding Pre‑NAT and Post‑NAT Enforcement Order

Stateful edges separate NAT from access control to preserve connection‑tracking semantics. The two canonical models are:

Knowing which step occurs first is essential for tracing the policy path that decides allowance or denial. Operators must verify that the identity used in the pre‑NAT check matches the expected identity after NAT, and vice‑versa for the return direction.

Stateful Edge Architecture

Components of a Stateful Edge

1. Ingress interface – receives packets from an untrusted or semi‑trusted network.
2. NAT engine – performs source, destination, or static translation, maintaining a translation table.
3. Stateful inspection engine – tracks TCP/UDP/ICMP sessions, creates conntrack entries, enforces sequence‑number checks.
4. Policy engine – evaluates security policies (ACLs, security rules) either before or after NAT, depending on platform.
5. Egress interface – forwards packets toward the destination network.
6. Logging and monitoring subsystem – records policy hits, NAT translations, and session creation/teardown.

Each component contributes to the rendered → applied → observed transformation. Misalignment between any two states can produce symptoms that look like policy misconfiguration when the root cause is NAT‑induced identity shift.

Role of NAT in Stateful Edge Architecture

NAT serves two primary purposes:

• Address conservation – maps multiple internal hosts to a smaller set of public IPs (PAT) or provides stable external addresses for services.
• Topology hiding – prevents external observers from learning the internal addressing scheme, reducing the attack surface.

Because NAT rewrites source or destination IP/port, the identity that the policy engine sees changes at the NAT boundary. If a policy references the original addresses (e.g., an address group containing 10.0.0.0/24), a packet that has undergone source NAT will no longer match that group in the post‑NAT evaluation, causing a deny even though the pre‑NAT evaluation allowed it.

Comparing Intended Segmentation Policy with Actual Enforcement

Pre‑NAT Enforcement Order

Platforms that evaluate policy before NAT (Cisco ASA pre‑8.0, Juniper SRX, Palo Alto pre‑NAT view) match the packet against the security rule set using the original source/destination addresses and zones. The outcome determines whether the packet proceeds to the NAT engine:

• Allow → packet enters NAT engine.
• Deny → packet dropped; no NAT translation created.

Post‑NAT Enforcement Order

After NAT translation, many platforms perform a second policy lookup using the translated addresses. This step is often invisible in the rule base but is a distinct evaluation point:

• Allow → session created, traffic flows.
• Deny → session torn down (or never created); packet dropped, even though the pre‑NAT check passed.

Identifying Discrepancies between Intended and Actual Policy

To detect a mismatch, compare these artifacts:

If the pre‑NAT counter increments but the post‑NAT counter does not (or a deny log appears after NAT), the policy path diverged at the NAT boundary.

Troubleshooting One‑Way Failure Scenarios

Understanding One‑Way Failure in Stateful Edge

A one‑way failure occurs when traffic flows successfully in one direction but not the opposite, despite symmetric policy intent. In a stateful edge with NAT, this often manifests as:

• Forward direction (client → server): Pre‑NAT allow → NAT translation → post‑NAT allow → session established.
• Reverse direction (server → client): The return packet arrives at the edge with the translated source address (the public IP) and the original destination address (the client’s private IP). If the post‑NAT policy expects the original private address as the source, the packet fails the post‑NAT check and is dropped, breaking the TCP handshake or causing an application‑level timeout.

The failure is “one‑way” because the forward path never sees the post‑NAT deny (the packet is already translated before the policy check), whereas the reverse path sees the deny after NAT.

Example of a Valid Allow Rule Yielding One‑Way Failure

Consider the following intended policy on a Juniper SRX:

# Intended policy (rendered)
security {
    policies {
        from-zone Trust to-zone DMZ {
            policy allow-web {
                match {
                    source-address 10.0.0.0/24;
                    destination-address 172.16.10.0/24;
                    application junos-https;
                }
                then {
                    permit;
                }
            }
        }
    }
}

And a source NAT rule that hides the Trust zone behind a single public address:

nat {
    source {
        rule-set trust-to-inet {
            from zone Trust;
            to zone untrust;
            rule src-nat {
                match {
                    source-address 10.0.0.0/24;
                }
                then {
                    source {
                        nat {
                            interface;
                        }
                    }
                }
            }
        }
    }
}

Flow analysis:

1. Client (10.0.0.5) initiates HTTPS to web server (172.16.10.20).

   • Pre‑NAT policy check: source 10.0.0.5 ∈ Trust, dest 172.16.10.20 ∈ DMZ → allow.
   • NAT engine translates source to 203.0.113.10 (public IP).
   • Post‑NAT policy check (if any) sees source 203.0.113.10, dest 172.16.10.20. Assuming no explicit post‑NAT deny, the packet is permitted and a session is created.

2. Server replies with SYN‑ACK from 172.16.10.20 to 203.0.113.10.

   • The packet arrives at the SRX on the untrust interface.
   • Pre‑NAT policy check: source 172.16.10.20 (DMZ) → destination 203.0.113.10 (untrust). The policy allow-web expects source-address 10.0.0.0/24, so no match → packet falls through to the implicit deny rule and is dropped.
   • Because the packet is dropped pre‑NAT, no session lookup occurs, and the client perceives a timeout.

Thus, a perfectly valid allow rule (intended to permit Trust→DMZ HTTPS) yields a one‑way failure because the return‑path identity (the NAT‑translated address) does not match the identity expected by the policy.

Step‑by‑Step Troubleshooting Guide

1. Confirm the symptom

   • Use ping or tcpdump to verify forward traffic reaches the server but return traffic does not reach the client.
   • Look for asymmetric SYN‑SYN/ACK patterns in captures.

2. Gather rendered configuration

   • Juniper: show configuration | display set | match "security policies"
   • Cisco: show running-config | include access-list
   • Verify the rule references the correct source/destination objects.

3. Inspect NAT translation

   • Juniper: show security nat source
   • Cisco: show ip nat translations
   • Note the translated address/port used for the flow.

4. Check pre‑NAT hit counters

   • Juniper: show security policies hit-count – look for the rule’s pre‑NAT counter increment on forward traffic.
   • Cisco: show access-list – verify the ACL hit count.

5. Check post‑NAT hit counters or logs

   • Juniper: show security flow session – see if a session exists for the reverse direction.
   • Juniper: show log security-traffic – look for deny messages indicating a pre‑NAT mismatch.
   • Cisco ASA: show asp table classify and show asp table nat to see where the packet was classified.

6. Correlate the identity

   • Compare the NAT‑translated source address seen in step 3 with the source-address match criteria in the security policy.
   • If they differ, the post‑NAT (or pre‑NAT on return) evaluation will fail.

7. Test a hypothesis

   • Temporarily add a more permissive rule that matches the translated address (e.g., source-address 203.0.113.0/24) and observe if return traffic succeeds.
   • If it does, the root cause is confirmed as an identity mismatch.

8. Restore and remediate

   • Adjust the security policy to reference the post‑NAT identity (or use a NAT‑aware identity such as a dynamic address group that tracks the NAT pool).

By following this guide, operators can quickly identify and resolve one‑way failures caused by NAT‑induced identity shifts, ensuring that intended segmentation policies are enforced correctly in both directions.