The Juniper community thread titled "SRX300 IDP setup: Either configure idp or idp-policy and not both" captures the most common IDP confusion: the CLI offers applications-level IDP and policy-attached IDP, and mixing them leaves you with a config that commits but inspects nothing. IDP engagement has four prerequisites, and each one fails silently.
Prerequisite 1: Exactly One IDP Attachment per Policy
A security policy can reference IDP two ways, and the error message tells you when both are present:
set security policies from-zone TRUST to-zone UNTRUST policy WEB then permit application-services idp-policy IDP-BASE
# NOT also:
set security policies ... application-services idpidp (the simple flag) enables the recommended-base policy implicitly; idp-policy <name> attaches your named policy. Choose one. Juniper's IDP policies documentation describes the rule-by-rule attachment model — IDP runs only where a security policy with IDP application-services matched the traffic.
Prerequisite 2: The Signature Database Is Loaded
show security idp security-package version
show security idp statusAn empty or failed signature package means every IDP policy matches nothing. Check that the package downloaded and installed (a valid license or trial, reachable update server), and that the running policy reflects the installed version. IDP without a current database is theater — schedule updates like the critical security items they are.
Prerequisite 3: The Policy Actually Loaded
show security idp policy-logs
show security idp active-policy
show log messages | match IDPactive-policy must show your policy name and its rulebase rule count. A policy that fails to load (rule conflicts, unsupported rule types on your platform) leaves the previous or default policy running while your config looks right — this is the quiet failure in most "IDP not working" threads. The IDP engine also adds real load: an inspection rulebase on a small SRX is a legitimate contributor to the symptoms in our RE high-CPU guide, so scope inspection rules to the traffic that matters.
Prerequisite 4: Traffic Matches the Security Policy with IDP Attached
IDP never sees traffic that a different security policy (one without IDP application-services) matched first. Policy lookup is top-down; a broad permit higher in the policy list shadows your IDP-attached rule:
show security match-policies from-zone TRUST to-zone UNTRUST source-ip 10.1.1.5 destination-ip 203.0.113.10 destination-port 443 protocol tcpThis command is the ground truth: it shows which policy wins for the exact flow you care about. If the winner lacks IDP services, reorder policies. The evaluation model comes from the zone/policy mechanics in the SRX zone-based firewall guide.
Verify Inspection Is Real
show security idp counters
show security idp attack-tableGenerate a known-bad test pattern (a port-scan or a flagged URL from your rulebase) and watch counters climb and policy-logs appear. Counters that never move during a deliberate test mean one of the four prerequisites above is unmet — recheck in order.
Quick Checklist
| Check | Command |
|---|---|
| One IDP attachment per policy | show configuration security policies | match idp |
| Signatures installed and current | show security idp security-package version |
| Your policy is active | show security idp active-policy |
| Flow matches the IDP policy | show security match-policies ... |
| Inspection counters moving | show security idp counters |
With inspection verified, layer it into the full SRX picture: screens and thresholds from the SRX screens tuning guide, VPN and NAT interaction from the IPsec troubleshooting guide and the NAT flow-session method — IDP sits on top of all of them and inherits their failure modes.
Discussion (0)