JNCIP-SEC common mistakes
JNCIP-SEC · Understand the traps and how to avoid them.
Explains a denied or unexpected flow by reading policy order and then-actions from the configuration only, never confirming which policy actually matched at runtime - so a wrong application (junos-http vs a custom port), an earlier broader policy, or the wrong zone pair from a multi-unit interface is missed.
Junos security policy is first-match, and the from-zone is derived from the ingress interface's zone, so a trunk whose unit 100 sits in a different zone changes the zone pair for that traffic. Config-only reading hides both facts.
What to do instead
Run show security match-policies from-zone trust to-zone untrust source-ip 10.1.1.10 destination-ip 203.0.113.5 source-port 51515 destination-port 443 protocol tcp, confirm ordering with show security policies hit-count, and read the matched policy and NAT flags from show security flow session extensive.
Chases management- and control-plane failures (ping to a reth address, OSPF hellos, IKE arriving on the external interface) with security policies, adding permit rules that never change the outcome.
Traffic destined to the device itself is governed by zone host-inbound-traffic (system-services and protocols), or by the junos-host zone for self-originated and self-terminated traffic - not by inter-zone policy.
What to do instead
Check show security zones and add set security zones security-zone untrust host-inbound-traffic system-services ping and ... protocols ike ospf; remember both cluster nodes and the fabric links need equivalent host-inbound config, and confirm counters with show security flow statistics.
Runs `show security policies` from the master admin context in a multi-tenant design, sees nothing, and concludes the tenant policy is broken; or assigns the same physical interface to both the master logical system and a tenant and hits a commit error.
Policies, zones, addresses and NAT rules are scoped to the logical system context, and an interface can be owned by only one logical system (or the master) at a time.
What to do instead
Enter the tenant context with set cli logical-system LS1 (or qualify commands with logical-system LS1), verify interface ownership with show configuration logical-systems LS1 interfaces and show interfaces terse, and confirm the tenant user's login class actually grants logical-system access.
Deploys the SRX in transparent mode and then troubleshoots with route lookups, static routes and source NAT rules; also mismatches VLAN IDs or access/trunk modes between the two bridge ports.
Transparent mode forwards at Layer 2 inside a bridge domain - there is no routing and no NAT - and a VLAN ID or interface-mode mismatch silently keeps the MAC out of the bridge table, so nothing is even dropped by policy.
What to do instead
Verify family ethernet-switching on both ports and matching bridge-domains ... vlan-id / interface-mode, then check show bridge domain, show bridge mac-table and show ethernet-switching table; move any routing or NAT requirement out of transparent mode entirely.
Writes a destination NAT rule but keeps the security policy matching the original public destination address, then reports a policy deny on traffic that should have been translated.
Junos applies destination NAT before the policy lookup and source NAT after it, so the policy must match the translated (private) destination while still matching the pre-NAT source address.
What to do instead
Point the policy's destination at the NAT pool or private host address, and confirm sequencing with show security nat destination rule all plus show security flow session extensive, reading the translated address and NAT flags on the session.
Tests hairpin access from an internal host to the public NAT IP, or an inbound service that depends on reflexive mapping, sees it fail, and blames the security policy instead of the missing ARP and source NAT pieces.
Hairpin traffic re-enters the same interface, so the SRX must answer ARP for the NAT address on the internal interface and source-NAT that flow so return traffic comes back through the device; reflexive inbound sessions from VoIP or peer-to-peer clients need persistent NAT.
What to do instead
Enable proxy-arp on the internal interface for the NAT addresses, add a source NAT rule covering internal-to-NAT-IP traffic, and for reflexive cases configure persistent-nat with appropriate inactivity-timeout; verify with show arp and show security nat source persistent-nat-table.
Declares the VPN healthy as soon as IKE phase 1 shows established, without checking phase 2, proxy IDs / traffic selectors, or - on route-based tunnels - whether st0.0 is bound, zoned and reachable by a route.
Phase 1 and phase 2 fail independently; policy-based VPNs need matching traffic selectors at both peers, and route-based VPNs need bind-interface st0.0, a zone assignment, a matching zone-pair policy, and a route pointing into the tunnel.
What to do instead
Check show security ike sa, show security ipsec sa and show security ipsec statistics, compare proxy IDs on both ends, and for st0 confirm show interfaces st0.0 and show route <remote-subnet>; enable security ike traceoptions with flag all to read the failing notify payload.
Builds an APBR rule matching a dynamic application and expects traffic to take the alternate routing instance, but the ingress zone has no application tracking, so applications resolve as unknown and the rule never matches.
APBR depends on AppID results, which require application-tracking on the ingress zone; the session must also be permitted by a security policy before APBR acts, and the target routing instance needs a usable next hop.
What to do instead
Add set security zones security-zone trust application-tracking, confirm signatures are loaded, validate the routing instance with show route table <ri>.inet.0, and inspect matches via show security flow session extensive and APBR traceoptions.
Configures reth interfaces and redundancy groups, then assumes failover is automatic: no interface-monitor weights, no reth-count consistency, and no planned failover test ever performed.
A redundancy group only fails over on a monitored object failure (interface, IP monitoring or heartbeat). Without interface-monitor entries and a consistent reth-count, a dead uplink can leave the node primary and black-holing traffic.
What to do instead
Add set chassis cluster redundancy-group 1 interface-monitor ge-0/0/1 weight 255 on both nodes, set reth-count, verify with show chassis cluster interfaces and show chassis cluster status redundancy-group 1, then rehearse with request chassis cluster failover redundancy-group 1 node 1 while watching show security flow session redundancy.
Attaches a UTM/IPS profile to a policy and expects blocking, but the profile action is still alert/recommended, the policy lacks `then ... application-services utm-policy`, or the tested traffic is HTTPS with no SSL forward proxy configured.
UTM profiles are inert unless referenced in the policy's then-clause, their default actions are detection-oriented rather than drop, and encrypted sessions are never inspected without SSL proxy or a decrypt profile.
What to do instead
Set explicit block actions in the profile, attach it with set security policies from-zone trust to-zone untrust policy P1 then permit application-services utm-policy UTM1 (plus an ssl-proxy profile for HTTPS), and confirm hits with show services utm statistics and show security flow session extensive.