Internal Users Cannot Reach a Destination-NAT Web Server
An SRX345 publishes an internal web server at 10.10.10.100:443 to the Internet using destination NAT. The public address 203.0.113.10/32 is on the untrust interface ge-0/0/0.0, and proxy ARP is enabled for it. The destination NAT rule matches from-zone untrust to-zone trust, destination 203.0.113.10/32 port 443, and translates to 10.10.10.100 port 443. External clients can connect. Internal clients on 10.10.10.0/24, the same subnet as the server, cannot connect to https://203.0.113.10; they time out. The trust interface is ge-0/0/2.0 (10.10.10.1/24). A trust-to-untrust permit policy exists for all applications. show security flow session destination-prefix 203.0.113.10 shows only sessions sourced from public addresses. show security nat destination rule all shows the rule with hit count from external clients only.
1. Why do external clients succeed while internal clients on the same subnet fail? Explain the NAT rule match and the Layer 2 return-path problem.
Read the worked answer
The external client succeeds because its packet arrives on the untrust interface, matches the destination NAT rule from-zone untrust to-zone trust, is translated to 10.10.10.100, and is then routed to the server. The return traffic from the server goes back through the SRX because the server's default gateway is the SRX, and the stateful session handles it.
The internal client is different in two ways. First, its packet arrives on the trust interface, so the existing destination NAT rule with from-zone untrust does not match. The SRX therefore routes the packet toward 203.0.113.10 on the untrust side instead of translating it to the internal server, and the connection fails. Second, even if a trust-to-trust destination NAT rule were added, the client and server are in the same 10.10.10.0/24 subnet. The server would receive the packet with the client's real source address and would ARP directly for the client, bypassing the SRX on the return path. The flow would be asymmetric and the session would not complete. That is why hairpin NAT requires both destination translation and source translation.
2. Describe the NAT rules needed for hairpin access and the verification that proves both translations occurred.
Read the worked answer
Add a destination NAT rule for the hairpin path: from-zone trust to-zone trust, destination 203.0.113.10/32 port 443, translated to 10.10.10.100 port 443. This makes the internal client's packet match a NAT rule on ingress rather than being routed to the Internet. Then add a source NAT rule for the same hairpin path so the server's return traffic is forced back through the SRX. The source NAT rule should match the internal client subnet and the translated server address, or the relevant trust-to-trust traffic, and translate the client source to an address owned by the SRX, such as the trust interface address or a dedicated hairpin pool. The security policy must also permit trust-to-trust traffic to the server; if both interfaces are in the same zone, an intra-zone policy is required.
Verify with show security flow session destination-prefix 10.10.10.100/32 and extensive output. The session should show both the destination translation from 203.0.113.10 to 10.10.10.100 and the source translation from the client address to the SRX-owned address. Check show security nat destination rule all and show security nat source summary for incrementing hit counts. Finally, test from an external client again to confirm the original untrust-to-trust rule still works and that the new trust-to-trust rules did not shadow it.