HTTP Block Policy, HTTPS Exception, and a Monitoring Host
An SRX345 running Junos 22.4R2 protects a small data center. The trust zone contains ge-0/0/1.0 (10.20.0.1/24); the untrust zone contains ge-0/0/0.0 (198.51.100.2/30). The address book entry web-farm is 203.0.113.10/32. Three policies are ordered as follows: (1) block-legacy, trust to untrust, source any, destination web-farm, application junos-http, deny; (2) allow-web, trust to untrust, source users (10.20.0.0/24), destination web-farm, application junos-https, permit; (3) default-deny. The security requirement is to block cleartext HTTP to web-farm for all users. A monitoring server at 10.20.0.50 must be allowed to poll http://203.0.113.10/health. Users report that HTTPS works but HTTP fails. show security flow session destination-prefix 203.0.113.10 shows only 443 sessions. show security policies hit-count shows block-legacy at 14 hits and allow-web at 220 hits. No commit errors are present.
1. Is the HTTP failure a fault or expected behavior? Explain using policy order, zone context, and application matching, and state what you would check before changing anything.
Read the worked answer
This is expected behavior for ordinary users, not a policy bug. The SRX evaluates policies top-down for the trust-to-untrust zone pair. block-legacy is first and matches source any, destination web-farm, and application junos-http, which is TCP/80. A normal HTTP request therefore hits block-legacy and is denied before allow-web is evaluated. HTTPS still works because junos-http does not match TCP/443; the packet skips the first policy, matches allow-web with junos-https, and is permitted.
The hit counts support that interpretation: the deny policy has hits, and the permit policy has many more hits from HTTPS. The flow-session output showing only 443 sessions is also consistent. Before changing anything, confirm that the business requirement really is to block HTTP for everyone, confirm the zone pair and policy order with show security policies from-zone trust to-zone untrust, and confirm the application definition being used. If the requirement is to block HTTP, the only gap is the monitoring exception at 10.20.0.50. If the user expected HTTP to work generally, the fault is in the requirement or policy order, not in Junos.
2. The monitoring server must reach http://203.0.113.10/health, but no other host may use HTTP. Describe the policy you would add, where it must be placed, and how you would prove that it does not open HTTP to everyone.
Read the worked answer
Create a narrow exception above the deny. Define an address book entry for the monitoring host, for example monitor-host as 10.20.0.50/32, then add a policy before block-legacy: from-zone trust to-zone untrust, source monitor-host, destination web-farm, application junos-http, action permit, with logging enabled. The order must be exception first, then block-legacy, then allow-web, then default-deny. If the exception is placed below block-legacy, the deny wins and the monitor still fails.
Verification should be two-sided. First, generate the health check from 10.20.0.50 and confirm a new session with show security flow session source-prefix 10.20.0.50/32 destination-prefix 203.0.113.10/32; the session should show TCP/80. Second, confirm the exception's hit count increments with show security policies hit-count. Third, generate HTTP from a different trust host, such as 10.20.0.60, and confirm it still hits block-legacy and not the exception. Also check the monitor's actual URL: if it uses TCP/8080, junos-http will not match and a custom application or service must be used.