Hairpin NAT for an Internal Web Server

The inbound path works because packets from the Internet enter the untrust interface, where the destination NAT rule set is applied, and are translated to 172.16.10.10 before the security policy is evaluated. The trust-to-public path is different. The packet from a trust host to 203.0.113.10 enters the trust interface, but the destination NAT rule set is bound to untrust, so it is not evaluated on the trust ingress. The SRX then routes the packet toward its default route or treats the destination as local, depending on addressing, and the translation to the DMZ server never happens. Even if the packet somehow reaches the server, the return path would not match the original flow cleanly. The policy trust-to-dmz being any does not help, because the packet is not being destination-NATted into the DMZ. This is a NAT-application problem, not a missing security policy. That is why internal users can reach 172.16.10.10 directly but not the public address.

Add a destination NAT rule set bound to the trust interface that matches destination 203.0.113.10/32 and statically translates it to 172.16.10.10. Add a source NAT rule for trust-to-dmz so the server replies to the SRX's DMZ address rather than to the original 10.20.x.x client; interface source NAT on the dmz interface is the usual choice. Confirm the trust-to-dmz policy permits HTTPS to 172.16.10.10. The processing order matters: the SRX evaluates destination NAT before source NAT, so the packet is first translated to the private server address, then source-NATted for the return path. The security policy then sees the translated destination. Without the trust-bound destination NAT rule, the public address is never mapped on that ingress. Without source NAT, the server may reply directly to the client and bypass the SRX, producing an asymmetric flow that is dropped. Verify with a flow trace and session table showing both translations.

Hairpin NAT keeps a single URL and public certificate for all users, but it adds translation state and makes troubleshooting harder because internal and external clients use different NAT paths to the same server. It also consumes SRX sessions and can complicate logging because the original source is hidden unless you log pre-NAT information. Split-horizon DNS is simpler on the firewall: internal clients resolve the server to 172.16.10.10 and take a direct trust-to-dmz path, while external clients resolve to 203.0.113.10. The trade-off is DNS complexity and the risk of inconsistent records or certificate name mismatches if the internal name differs. Split-horizon DNS also avoids the hairpin performance cost and is usually easier to audit. If the application must present the same public name internally, hairpin NAT is justified; otherwise I would prefer split-horizon DNS for operational simplicity.