JNCIA-SEC common mistakes
JNCIA-SEC · Understand the traps and how to avoid them.
Reading the SRX policy evaluation order as 'policy first, then zones' and expecting a policy to match traffic that enters an interface not bound to the policy's from-zone, then choosing a 'permit any' workaround instead of fixing zone membership.
Candidates learn policy syntax (match conditions, then actions) before they internalise the packet-processing pipeline: ingress zone lookup, then screen/flow checks, then policy lookup keyed on the (from-zone, to-zone) pair. Because a policy simply won't appear in 'show security flow session' output when the zone pair is wrong, the failure looks like a policy bug rather than a zone-binding bug.
What to do instead
Before debugging a policy, verify the interface-to-zone binding with 'show configuration security zones' and confirm the session's zone pair in 'show security flow session extensive'. Trace one packet mentally through: ingress interface -> zone -> policy lookup for that zone pair -> action. Practise with a deliberately mis-zoned interface so the symptom (policy silently never matched, counters at zero) becomes recognisable.
Treating NAT as a routing or policy substitute: placing a source NAT rule and then assuming the matching security policy will also permit the traffic, or assuming NAT alone makes an internal host reachable from the internet.
NAT and policy are independent rule sets evaluated at different points. A source NAT rule rewrites the source address but the translated flow still needs a policy that matches the original pre-NAT (or in some designs post-NAT) addresses and the correct zone pair. Candidates who configure NAT in a lab and see it 'work' often had a permissive policy already in place and never learned the dependency.
What to do instead
For every NAT scenario, write down four things: original source, translated source, original destination, translated destination, and which policy must match which of these. Test with logging enabled on the policy so you can see whether the flow was denied before or after translation. Remember destination NAT also requires a route back to the real server and, on many designs, a corresponding policy referencing the pre-NAT or post-NAT address per your configuration.
Confusing the order of the three NAT types (source, destination, static) and the order rules within a rule set, then concluding NAT 'isn't working' when a broader rule earlier in the set is shadowing the intended rule.
Rule sets are evaluated in order and the first match wins; a catch-all source NAT rule placed above a more specific one will silently capture traffic. Candidates often build rules top-to-bottom as they think of them rather than ordering specific-before-general, and the SRX gives no warning.
What to do instead
Adopt a habit of placing specific rules above general ones and reviewing the full rule set with 'show security nat source rule all' (and the destination/static equivalents). When a translation looks wrong, check which rule actually matched using session output showing pre- and post-translation addresses, not just the configuration order you intended.
Believing that creating an IPsec VPN (IKE gateway, IPsec policy, VPN, and binding it to a tunnel interface or st0) is sufficient for traffic to flow, and then not creating a security policy permitting traffic between the relevant zones over the tunnel.
Phase 1 and Phase 2 coming up gives a satisfying 'UP' status, which candidates read as 'the VPN works'. The tunnel only carries traffic; the security policy still governs whether the traffic is allowed, and the tunnel interface must be in a zone with a policy to the protected zone. This is the single most common reason a green VPN shows no passing traffic.
What to do instead
After verifying IKE and IPsec SAs, immediately check the policy set for the tunnel zone pair. Build a checklist: IKE gateway (peer address, preshared key, proposals) -> IPsec policy/proposal -> VPN binding -> st0 interface with correct zone -> route to remote subnet via st0 -> policy from tunnel zone to trust zone. Verify each with 'show security ike sa', 'show security ipsec sa', and 'show security flow session'.
Mismatching Phase 1 or Phase 2 parameters (encryption/hash/DH group, or proxy IDs) between peers and then guessing at the fix by changing one side repeatedly rather than comparing both configurations.
Proposals must match exactly, and proxy-ID mismatches produce a Phase 2 failure that looks identical in the logs to an encryption mismatch. Candidates often only have visibility into one device, so they change parameters on the device they can see and hope the other side matches.
What to do instead
Capture both peers' Phase 1 and Phase 2 proposals side by side before changing anything. Use 'show security ike sa detail' and 'show security ipsec sa detail' to see which phase is failing, and check logs for the specific notify payload (e.g. NO_PROPOSAL_CHOSEN indicates a Phase 1 proposal mismatch; a Phase 2 failure with SAs absent points at proxy IDs or Phase 2 proposals). Fix the mismatched field, clear the SA, and retest.
Enabling AppSecure or UTM features and expecting them to apply, without confirming the profile is attached to the correct policy and that the traffic actually matches that policy.
Application security and UTM are policy actions, not global switches. A UTM profile configured but not referenced in the permit policy does nothing. Candidates also forget that application firewall rules and UTM inspection happen after the policy permits the session, so a deny earlier in the policy set bypasses all inspection.
What to do instead
For each security feature, trace the chain: policy match -> policy action permits -> profile attached to that policy -> feature enabled. Verify with 'show security flow session' to see which policy matched and whether the session shows the expected application or UTM inspection, and check feature-specific counters and logs rather than assuming configuration equals enforcement.
Treating IPS signatures as 'set and forget' and misreading a lack of alerts as 'no attacks', when the real cause is that the traffic never reached the inspection point or the signature set does not cover the protocol in use.
IPS operates on permitted sessions and depends on correct protocol context. Encrypted traffic, traffic bypassing the device, or signatures filtered to a narrow category will produce no alerts regardless of attack traffic. Candidates then misdiagnose a detection gap as a clean network.
What to do instead
Validate IPS by testing with a known-benign signature or a controlled test pattern that should trigger, confirming the alert appears in logs. Check that the IPS profile is attached to the policy, that the session is being inspected, and that the signature set includes the relevant category and severity. Read signature details to confirm the protocol and direction it applies to.
Using 'show configuration' output as proof that a feature is active, and never checking runtime state, commit status, or whether the configuration was committed at all.
Junos separates candidate configuration from the active configuration. A candidate edit that was never committed, or a commit that failed validation, leaves the running device unchanged while the candidate shows the intended design. Candidates who only read the candidate config conclude the device is misbehaving.
What to do instead
Always separate the two questions: 'what is configured?' and 'what is running?'. Use 'show configuration | compare' to see uncommitted changes, check commit history with 'show system commit', and confirm the feature's runtime state with the relevant operational command. Make 'did this commit succeed?' a reflex before any deeper troubleshooting.
Debugging with packet captures or traceoptions on a production-looking flow without first confirming the session exists and which policy matched, then chasing a phantom routing or NAT problem.
Traceoptions and captures generate a lot of output and are attractive because they feel like 'real evidence'. Without first establishing whether a session was created, which policy matched, and where the packet was dropped, the capture output is interpreted against the wrong hypothesis, and candidates burn exam time on irrelevant detail.
What to do instead
Follow a fixed triage order: session lookup ('show security flow session'), then policy match and counters ('show security policies hit-count'), then zone and route checks, then targeted traceoptions only for the specific stage in doubt. Narrow traceoptions to a single flow with a filter so output is readable, and always turn them off afterwards.
Ignoring logging and syslog configuration until troubleshooting, then being unable to answer 'was this denied, and why?' because session logging and policy logging were never enabled and no stream/log destination exists.
Denied traffic is often silent by default, and session close logs require logging enabled on the policy. Candidates treat logging as an afterthought, so during an incident or exam scenario there is no evidence trail and they must guess at the deny reason.
What to do instead
Make logging part of every policy you build: enable session logging on permit policies and log on deny where appropriate, and configure a syslog host or log stream so events leave the device. Practise reading a session close log to extract the policy name, the deny reason, and the byte counts, since that is the fastest path from symptom to cause.