Retail DMZ Policy Order, Host-Inbound Ping, and Missing Source NAT
A retail chain is commissioning a payment gateway at a store. The SRX345 has ge-0/0/1 in trust (10.20.0.0/24), ge-0/0/2 in dmz (172.20.5.0/24), and ge-0/0/0 in untrust (198.51.100.2/30, default route 198.51.100.1). The gateway is 172.20.5.10/24 with default gateway 172.20.5.1. Administrators in trust must SSH to the gateway and must also ping the SRX dmz interface. The gateway must query NTP server 203.0.113.20. The trust-to-dmz policy set contains, in order: (1) a rule matching source any, destination any, application any, action deny; (2) a rule matching 10.20.0.0/24 to 172.20.5.10 with junos-ssh, action permit. The dmz-to-untrust policy set contains one rule: 172.20.5.10/32 to 203.0.113.20/32 with junos-ntp, action permit. No NAT is configured. The dmz zone has no host-inbound-traffic services configured. Symptoms: SSH to 172.20.5.10 times out; ping to 172.20.5.1 fails; the gateway NTP packets leave the SRX but no replies arrive.
1. Explain each of the three symptoms and name the mechanism responsible.
Read the worked answer
SSH to 172.20.5.10 is transit traffic from trust to dmz. Security policies are first-match, so the deny-any-any rule at position 1 matches and the junos-ssh permit at position 2 is never evaluated; the session is dropped before it is created. Ping to 172.20.5.1 is different: the destination is the SRX itself, so it is host-inbound traffic on the dmz zone. show security flow session will not show a transit session for it. The dmz zone has no host-inbound-traffic services, so junos-ping is not allowed even though a trust-to-dmz policy exists. NTP is transit dmz-to-untrust and the policy permits it, but no source NAT is configured. The SRX forwards the packet with source 172.20.5.10; the public NTP server cannot route a reply to a private address. The outbound session may exist, but no reply returns.
2. Give the corrected configuration approach and the commands you would use to verify each layer.
Read the worked answer
Remove or move the deny-any-any rule below the specific permit, or replace it with a deny only for traffic that should be blocked; keep least privilege. For the SRX ping, add set security zones security-zone dmz host-inbound-traffic system-services ping (and only the services needed). For NTP, add source NAT from dmz to untrust for 172.20.5.10/32, using the untrust interface address or a small pool, and confirm the default route on the SRX and the return path. Verify with show security policies and hit counts, show security flow session destination-prefix 203.0.113.20 to see NAT flags, show security nat source rule all, and show configuration security zones security-zone dmz. Remember that host-inbound is evaluated for traffic to the device, while security policy is for transit; mixing them up is the common error.
3. If administrators also need to SSH to the SRX itself from trust, what changes and why?
Read the worked answer
That is host-inbound SSH on the trust zone, not a trust-to-dmz policy. Add set security zones security-zone trust host-inbound-traffic system-services ssh if it is not already present, and restrict it with host-inbound-traffic protocols or a firewall filter/allow-list if possible. The existing trust-to-dmz junos-ssh policy only controls traffic passing through the SRX to the gateway; it does not authorize login to the device. Verify with show configuration security zones security-zone trust and test from a trust host. If SSH to the gateway still fails after the policy fix, check the gateway own firewall and the return route.