Destination NAT Before Policy Lookup on an SRX1500
An SRX1500 protects a small data center. Untrust is reth0.0 (198.51.100.1/24), trust is reth1.0 (10.20.0.0/16), and DMZ is reth2.0 (172.16.5.1/24). A web server at 10.20.5.20 listens on TCP 8443. The ISP routes 198.51.100.16/29 to the SRX, and the published address is 198.51.100.20. The administrator configured a destination NAT rule-set applied on reth0.0 that translates 198.51.100.20/32 port 443 to 10.20.5.20 port 8443, plus proxy ARP for 198.51.100.20 through 198.51.100.22. The untrust-to-trust policy matches destination address 198.51.100.20, application junos-https, action permit with log session-close. External clients now time out. A firewall filter on reth0.0 counts the arriving SYNs, and show security flow session shows no session for them. show security policies hit-count shows zero hits on the permit policy, and the flow trace reports a policy lookup failure. The server itself is healthy and reachable from the DMZ.
1. Explain why the permit policy records zero hits and what you would change. Include the NAT and policy ordering and the application object.
Read the worked answer
On SRX, destination NAT is applied before the security policy lookup. The policy therefore evaluates the post-translation tuple: destination 10.20.5.20, port 8443. The configured policy references 198.51.100.20 and junos-https, which is TCP 443. Neither the address nor the application matches, so the flow falls through to the default deny. The interface filter counts the SYNs because interface filters run before flow-based NAT and policy processing; the drop happens later, in policy lookup.
The minimum fix is to make the policy describe what the policy engine actually sees:
- Create an address object for 10.20.5.20, or use an existing DMZ address book entry.
- Create a custom application for TCP 8443;
junos-httpscannot be edited to include it. - Update the untrust-to-trust policy to match 10.20.5.20 and the TCP 8443 application, keeping the log action.
- Keep the destination NAT rule-set on reth0.0, and confirm proxy ARP still covers 198.51.100.20.
Verify with show security flow session for the translated tuple and show security policies hit-count showing hits, then confirm the server sees connections from the SRX's DMZ address.
2. The server must also initiate outbound connections to update.example.com and the remote side must see 198.51.100.20. What NAT and policy changes are needed, and in which order does source NAT occur?
Read the worked answer
Source NAT occurs after the policy lookup. The trust-to-untrust policy must therefore match the original source 10.20.5.20 and the destination update.example.com; the source translation is applied only after that policy permits the flow.
To make outbound traffic use 198.51.100.20, add a source NAT rule that matches source 10.20.5.20 and translates to a pool containing only 198.51.100.20/32. A single-address pool is acceptable for one server, but size it with the server's connection rate in mind: one address has a finite port range. If the server opens many concurrent connections, consider a small pool or persistent NAT rather than a single address, and document which external address the remote side will see.
Do not reuse a general interface source NAT rule ahead of this one, because the server would then egress with the reth0.0 address instead of 198.51.100.20. Order the rule-set so the server-specific rule is evaluated first, and keep the proxy ARP and the destination NAT for inbound traffic unchanged. Verify outbound translation with show security flow session and check that the remote side logs 198.51.100.20.
3. How would you prove the return path and ARP behavior are correct without packet capture on the server?
Read the worked answer
Work from the SRX outward. First, confirm the SRX answers ARP for the published address if the ISP's next hop is on-link: show arp should show 198.51.100.20, and show security nat proxy-arp should list the proxy entry. If the ISP routes the /29 to the SRX, the upstream router needs a route, not an ARP entry; check that distinction instead of assuming proxy ARP is always required.
Second, inspect the session in both directions. show security flow session for the inbound flow should show the original tuple 198.51.100.20:443 and the translated tuple 10.20.5.20:8443; the reply direction should show the reverse translation. For outbound traffic, confirm the pre-NAT source 10.20.5.20 and the post-NAT source 198.51.100.20 in the same session output.
Third, use monitor traffic interface reth0.0 matching arp and a short monitor traffic on the DMZ interface to see the SYN arrive and the SYN-ACK return. Finally, check show security policies hit-count and the deny logs: a zero hit count on the permit policy is the fastest proof that the policy tuple, not the return path, is still wrong.