Hairpin Destination NAT for Internal Portal Users

The destination NAT rule-set is applied only on untrust. A trust-side packet to 203.0.113.10 is therefore not translated on ingress. The SRX routes it according to its table, which points toward the ISP, and the packet leaves untrust with the public destination still intact. Even if the ISP's upstream happens to hairpin the packet back, the return path and policy state do not line up, and the trust side has no matching permit. The interface filter counts the SYNs because interface filters run before flow processing; no session is created because the traffic never matches a valid stateful path.

Minimum fix:

• Apply the destination NAT rule-set on the trust interface as well, so the trust-originated packet is translated to 10.20.5.10:443 before policy lookup. Using a static NAT rule-set applied to both interfaces is an alternative that avoids duplicating the rule-set.
• Add a trust-to-trust policy for the translated tuple, or make the existing trust-to-DMZ policy apply if the route sends the translated packet to the DMZ zone. The policy must match what the policy engine sees after destination NAT: 10.20.5.10 and TCP 443.
• If the server's return path to the client bypasses the SRX, add a source NAT rule for the hairpin so the reply is forced back through the firewall.

Verify with show security flow session for both directions and confirm the client receives a SYN-ACK whose source is translated back to 203.0.113.10.

It is not automatically mandatory. If the client and server are in different subnets and the server's only route back to the client is through the SRX, the session is stateful and destination NAT reverse-translates the reply source to 203.0.113.10. The client sees the address it connected to, and the flow works without source NAT. In this design the DMZ server's default gateway is the SRX's DMZ interface, so the reply should return through the firewall once the ingress NAT rule-set and policy are fixed.

Source NAT becomes necessary when the reply can bypass the SRX. Examples: the client and server share a subnet, so the server replies directly at Layer 2; the server has a more specific route to the client subnet via another gateway; or the design uses asymmetric forwarding where the reply would leave through a different path. In those cases, source NAT hides the original client address from the server, forcing the reply to the SRX, which then reverse-translates both the destination and the source.

Do not add source NAT by reflex. Test the hairpin first with the corrected destination NAT and policy, inspect the session table for both directions, and add source NAT only if the reply path proves to be asymmetric or bypasses the firewall. Document the decision, because adding source NAT changes what the server logs and what application-level access controls see.

Proxy ARP matters on the untrust side. If the ISP's next hop is on-link for 198.51.100.0/24 and ARPs for 203.0.113.10, the SRX must answer for that address. If the ISP routes 203.0.113.0/24 or a larger block to the SRX, the upstream needs a route instead, and proxy ARP is irrelevant. Internal users route to their default gateway, which is the SRX, so they do not ARP for 203.0.113.10 at all; proxy ARP does not fix the internal failure.

Verification without DNS changes:

• Browse to the public URL by address, or use a local hosts entry on one test workstation, so the name resolution path is unchanged.
• Run show security flow session and confirm a session exists for 10.20.x.x to 203.0.113.10:443, with the translated destination 10.20.5.10:443 and a reply-direction entry showing the reverse translation.
• Check show security policies hit-count on the hairpin policy to confirm the policy, not just the filter, is matching.
• Use monitor traffic interface reth1.0 matching 203.0.113.10 to see the SYN enter and the translated reply leave toward the client.
• Confirm show arp and show security nat proxy-arp only if the ISP path uses on-link ARP; otherwise check the upstream route instead.