JNCIS-SEC common mistakes
JNCIS-SEC · Understand the traps and how to avoid them.
Treating the SRX as a stateless packet filter: writing a policy that permits traffic in one direction only and expecting return traffic to be evaluated by a separate policy, then being surprised when sessions appear in the session table and replies pass without a matching reverse policy.
Candidates carry over experience from stateless ACL platforms and from screen-based device configuration, and they never internalize that SRX is a flow-based, stateful device where the first packet creates a session and all subsequent packets of that flow are matched to the session rather than to policy.
What to do instead
Before answering any policy question, state the flow explicitly: packet arrives, zone lookup, policy lookup for the first packet only, session creation, then session-based forwarding. Practice by reading a session table output and identifying which policy created each session, and confirm that no reverse-direction policy is needed for a permitted flow.
Assuming that assigning an interface to a zone automatically permits traffic, and forgetting that the default security policy behavior on SRX is to deny inter-zone traffic while intra-zone traffic is permitted by default.
The candidate focuses on interface configuration and routing reachability and treats the zone as a labeling exercise, so they never check whether an explicit policy exists between the source and destination zones, nor do they recall that intra-zone traffic is allowed by default unless a policy or host-inbound restriction says otherwise.
What to do instead
Memorize the two defaults as a pair: inter-zone deny, intra-zone permit. When troubleshooting a blocked flow, verify zone membership of both interfaces, then check for a policy matching source zone, destination zone, source address, destination address, application, and action in that order of evaluation.
Configuring NAT but leaving the security policy written against pre-NAT addresses, so the policy never matches and traffic is dropped despite the NAT rule looking correct.
Candidates do not know the order of operations in the flow: destination NAT is resolved before the security policy lookup, while source NAT is applied after the policy lookup. They therefore write policies against the wrong address set for the NAT type in use.
What to do instead
Draw the pipeline once and keep it: ingress zone, destination NAT, routing decision, security policy, source NAT, egress. For destination NAT, write the policy against the translated (private) destination address; for source NAT, write the policy against the original source address. Verify with session table output showing both pre-translation and post-translation addresses.
Confusing interface NAT with proxy ARP behavior, or forgetting proxy ARP for destination NAT pools, resulting in traffic that arrives at the SRX but is never answered on the wire.
The candidate understands the NAT rule but not the address-resolution consequence: if the SRX owns a public address for destination NAT that is not configured on an interface, upstream devices cannot resolve it unless the SRX answers ARP for it.
What to do instead
For destination NAT using an address not bound to an interface, enable proxy ARP on the ingress interface and confirm the upstream router's ARP entry resolves to the SRX MAC. Check with show arp and by examining interface statistics for unanswered requests.
Mixing policy-based VPN configuration and route-based VPN configuration in the same tunnel, or expecting a policy-based tunnel to survive a routing change without a matching policy for the interesting traffic.
Candidates learn one style and apply its mental model to the other. Policy-based VPNs bind the tunnel to a specific policy and rely on proxy IDs, while route-based VPNs use a tunnel interface and a route, and the two have different failure signatures and different traffic selectors.
What to do instead
Decide the style first and stay consistent. For route-based, bind the tunnel interface to a zone, add a route pointing at it, and write a policy permitting traffic into that zone. For policy-based, ensure the policy action is tunnel with the correct VPN and that the proxy IDs match the peer exactly. Verify with show security ipsec security-associations and show security ike security-associations.
Assuming phase 2 is up because phase 1 is up, and not checking proposal mismatches, proxy ID mismatches, or that the correct pair of security associations exists for both directions.
The candidate treats IKE and IPsec as one negotiation and checks only the IKE SA, or checks only one direction, so they miss that phase 2 can fail independently on encryption or authentication algorithm mismatch, lifetime, or traffic selector mismatch.
What to do instead
Troubleshoot in order: verify phase 1 with show security ike security-associations, then phase 2 with show security ipsec security-associations, then check that both inbound and outbound SAs exist. Compare every proposal parameter and the traffic selectors on both peers, and read the kmd log for the specific mismatch reason.
Enabling a UTM feature such as antivirus, IPS, or content filtering in a feature profile but forgetting to attach the profile to the security policy, then concluding that UTM is not working.
The candidate configures the profile and stops there, missing the second binding step, or attaches it to the wrong policy, or attaches it to a policy that does not match the traffic because of NAT address ordering.
What to do instead
Remember that UTM requires two bindings: the feature profile, and the profile set referenced in the policy action. Confirm the policy actually matches the flow using session table output and hit counts, then verify the profile set is applied to that policy and that the relevant license is installed and the signature database is current.
Ignoring the difference between host-inbound traffic and transit traffic when troubleshooting management access, and blocking SSH or ICMP to the device itself by omitting host-inbound services on the zone.
The candidate applies transit-traffic reasoning to traffic destined for the device, not realizing that traffic to the SRX itself is governed by host-inbound service and protocol configuration on the ingress zone, not only by security policy.
What to do instead
When management access fails, check three things in order: the interface is in a zone, the required service (ssh, https, ping) is permitted as host-inbound on that zone, and a policy permits the traffic if required. Distinguish clearly between transit flows and flows terminated on the device.
Misreading the session table during troubleshooting, for example treating a session in a non-established state as a policy drop, or failing to use the available filters to isolate the specific flow.
Candidates do not know the session states and flags well enough to interpret them, and they do not practice filtering sessions by source, destination, or application, so they draw conclusions from an unfiltered dump.
What to do instead
Learn the common session states and what each implies: a session stuck before establishment points to a routing, ARP, or NAT problem rather than a policy drop, while no session at all points to a policy or zone problem. Practice filtering sessions by the five-tuple and by application, and correlate with policy hit counts and flow traceoutput.
Skipping the verification step after configuration: not committing, not testing with a real traffic flow, and not checking that the configuration actually took effect before moving to the next question.
Candidates treat configuration as the end of the task and, under time pressure, assume that entering a command means it is active. They also forget that candidate configuration must be committed and that a failed commit leaves the previous configuration running.
What to do instead
Adopt a fixed verification habit for every scenario: commit, confirm commit succeeded, then test with a specific flow and read the session table plus the relevant counter or log. If a commit fails, read the error and fix the specific statement rather than abandoning the change.