JNCIE-SEC common mistakes
JNCIE-SEC · Understand the traps and how to avoid them.
Building a security policy set that relies on first-match order without verifying the implicit final deny and the effect of policy ordering on traffic that matches multiple terms, then discovering during verification that legitimate sessions are dropped or that a less-specific permit shadows a more-specific deny.
Candidates carry over habits from filter writing where term order is intuitive, but Junos security policies evaluate top-down with a default deny-all and no implicit logging, so a permit placed above a deny silently overrides it and the final deny hides the real cause of drops.
What to do instead
After every policy edit, run a policy lookup (show security policies detail / match traffic against the ruleset) and confirm which term matches each flow. Deliberately place denies above broad permits, add a logged deny-all term at the bottom for visibility, and check session setup logs for 'denied by policy' versus 'no matching policy' messages to distinguish ordering errors from missing terms.
Treating zones as labels only: assigning interfaces to zones but forgetting host-inbound-traffic services, forgetting that a zone needs at least one interface before policies referencing it take effect, or leaving the untrust zone with management services open.
The zone is the policy enforcement anchor, and candidates focus on the policy text while overlooking that interface-to-zone binding, host-inbound-traffic, and screen options all gate whether traffic reaches the policy engine at all.
What to do instead
For each zone, explicitly configure system services and protocols under host-inbound-traffic, verify interfaces are bound with the correct zone, and test host-inbound behavior separately from transit behavior. Use show security zones and show interfaces extensive to confirm bindings, and keep management access confined to a dedicated management zone.
Configuring an IPsec VPN that comes up on phase 1 but never establishes phase 2, because proposals, policies, and traffic selectors do not match between peers, or because the proxy-IDs are asymmetric.
IKE and IPsec have separate proposal sets and policy stanzas, and candidates often fix one side only or assume a default proposal will negotiate, while mismatched lifetimes, PFS groups, or traffic-selector subnets break phase 2 silently.
What to do instead
Compare both peers term by term: IKE proposal (encryption, auth, DH group), IKE policy (mode, pre-shared key or certificate, identity), IPsec proposal (protocol, encryption, auth, PFS), and IPsec policy (perfect forward secrecy, traffic selectors). Use show security ike sa and show security ipsec sa to see which phase fails, enable traceoptions for IKE, and confirm traffic selectors are mirror images on each side.
Building NAT rules that translate correctly on the first packet but break return traffic or applications with embedded IP addresses, because source NAT, destination NAT, and static NAT were applied without tracing the full forward and reverse path.
NAT interacts with policies, routing, and ALGs; candidates verify with a single ping and miss that return traffic needs a matching reverse mapping, that destination NAT changes the post-translation policy lookup, or that applications like SIP and FTP embed addresses requiring an ALG.
What to do instead
Trace each flow end to end: pre-NAT and post-NAT addresses, which policy is evaluated before and after translation, and the reverse mapping. Use show security nat source summary, show security nat destination summary, and session detail output to confirm both directions translate. For address-embedding protocols, enable and verify the relevant ALG rather than relying on plain NAT.
Writing stateless firewall filters that drop or count the wrong traffic because the candidate forgets that Junos filters are evaluated in order with an implicit accept, and that a filter applied to the wrong direction or interface has no effect.
Filters on the loopback, transit interfaces, and management interfaces behave differently, and the implicit accept at the end means a filter that only counts traffic will pass everything. Direction (input versus output) and family (inet versus inet6) are easy to misapply.
What to do instead
Always end filters with an explicit discard or accept term and include a counter on each term. Verify application with show interfaces filters and show firewall, and test with a known flow while watching counter increments. Confirm the filter is applied to the correct interface, direction, and protocol family before concluding the logic is wrong.
Assuming a chassis cluster will fail over cleanly without validating redundancy groups, monitored interfaces, and session synchronization, so a test failover drops all sessions or splits the cluster.
Cluster behavior depends on control link and fabric link health, redundancy group priorities, and session sync being enabled; candidates configure clustering but never verify failover or check that sessions are actually synchronized.
What to do instead
Verify with show chassis cluster status, show chassis cluster interfaces, and show chassis cluster statistics. Confirm session synchronization is on, test a controlled failover (request chassis cluster failover redundancy-group), and check that reth interfaces and monitored interfaces are correctly assigned to redundancy groups. Confirm the control link is not shared with data traffic.
Using commit and rollback carelessly in a live troubleshooting scenario: committing partial changes without commit confirmed, or losing track of which configuration candidate is active during an outage.
Under time pressure candidates make incremental changes and commit immediately, and a bad change that severs management access cannot be rolled back remotely; also, multiple candidate configs or a forgotten commit-check timeout cause confusion.
What to do instead
Always use commit confirmed with a short timeout for risky changes, then commit to confirm once verified. Before changes, capture a baseline with show configuration | display set and save a rescue configuration. Use show system commit and rollback to return to a known-good state, and never leave a confirmed commit unconfirmed.
Overlooking that application services such as AppSecure, IDP, or UTM require policy-level enablement and profile attachment, and expecting inspection to occur just because the feature is licensed or configured globally.
Candidates configure application signatures or UTM profiles but forget to attach them to a security policy term, or attach them to a term that never matches, so traffic passes uninspected while appearing configured.
What to do instead
For each inspection feature, confirm the profile is attached to the specific policy term that matches the target traffic, then verify with show security flow session extensive that the session shows the expected application or profile. Use show security application-firewall or the relevant status command to confirm the service is active, and validate with test traffic that should be blocked.
Diagnosing connectivity failures without a systematic layer-by-layer method, jumping straight to policy edits while ignoring routing, ARP, screen options, and session state.
The exam rewards methodical isolation; candidates change policies repeatedly when the real fault is a missing route, an ARP failure, a screen drop, or a stale session not being cleared.
What to do instead
Follow a fixed sequence: interface status, zone binding, routing table for the destination, ARP resolution, screen counters, then policy match, then NAT, then session table. Use show security flow session, show route, show arp, and show security screen statistics in that order. Clear stale sessions with clear security flow session before retesting.
Treating automation as an afterthought: hand-editing configuration instead of using commit scripts, event scripts, or NETCONF/XML APIs, and failing to validate programmatic changes before applying them at scale.
The operations domain expects reproducible change management; candidates comfortable with CLI editing skip configuration groups, apply-groups, and scripted deployment, and then cannot explain how to push consistent changes across devices or verify them.
What to do instead
Structure shared settings in configuration groups, use commit scripts for validation and event scripts for automated response, and drive changes through NETCONF or the Junos XML API with a load-and-commit-check workflow. Always validate with a commit check or a dry run against a lab device before applying to production, and keep changes idempotent so reruns are safe.