Hairpin Access to a DNAT Web Server from the Trust Zone
A SaaS company hosts a customer portal on an internal web server at 10.0.5.80:8080 in a dmz. The SRX300 interfaces are trust 192.168.10.1/24, dmz 10.0.5.1/24, and untrust 203.0.113.5/29. The public address is 203.0.113.6. A destination NAT rule from untrust to dmz translates 203.0.113.6 port 80 to 10.0.5.80 port 8080, and an untrust-to-dmz policy permits TCP 8080; external customers can reach http://203.0.113.6 successfully. A source NAT rule from trust to untrust translates 192.168.10.0/24 to the untrust interface address. A trust-to-dmz policy permits TCP 8080 from 192.168.10.0/24 to 10.0.5.80. Internal staff at 192.168.10.50 cannot open http://203.0.113.6; the browser times out and the server sees no connection. The server default gateway is 10.0.5.1. You want internal staff to use the same public URL, not split DNS, and you do not want to expose the server on another port.
1. Why does the external URL work for internet users but time out for 192.168.10.50?
Read the worked answer
The destination NAT rule is scoped from-zone untrust to-zone dmz. A packet from 192.168.10.50 to 203.0.113.6 enters the trust zone, so it does not match that rule; destination NAT is not applied and the destination stays 203.0.113.6. The route lookup sends it toward the default route out untrust, and the source NAT rule for trust-to-untrust rewrites the source to the untrust interface address. The packet does not reach 10.0.5.80; it either goes to the ISP and is dropped or is routed back in a way that does not match the existing session. The trust-to-dmz policy never helps because the post-NAT destination was never changed to the dmz server. External users work because their packets enter untrust and match the from-zone untrust rule.
2. What NAT and policy changes implement hairpin access without split DNS?
Read the worked answer
Add a destination NAT rule from trust to dmz that matches destination 203.0.113.6/32 port 80 and translates to 10.0.5.80 port 8080. Order it before any broader destination NAT rule that could match. The security policy is evaluated after destination NAT, so the trust-to-dmz policy must permit the translated destination 10.0.5.80 and the translated port 8080, not just junos-http on port 80; use a custom application for TCP 8080 or the appropriate predefined service. Because the server default gateway is 10.0.5.1, its return traffic to 192.168.10.50 comes back through the SRX and matches the session, so source NAT is not strictly required. If the server had a different gateway, add source NAT from trust to dmz so the return path is symmetric. Verify with show security nat destination rule all and show security flow session source-prefix 192.168.10.50.
3. What would you check if the new rule still fails, and how would you prove where the packet is being dropped?
Read the worked answer
First check rule order and hit counts with show security nat destination rule all and show security policies hit-count; a broader rule above the hairpin rule may be winning. Then check the flow session: show security flow session source-prefix 192.168.10.50 destination-prefix 203.0.113.6 shows whether destination NAT was applied and whether the session is active. If no session exists, run a flow trace with set security flow traceoptions for the source and destination, or a packet capture on trust and dmz interfaces. A capture on trust shows the original destination; a capture on dmz should show 10.0.5.80:8080. If the dmz capture shows the packet but no reply, the server local firewall or default gateway is the issue, not NAT.