Scenario practice questions

BGP autonomous system number

Why it fails: A BGP autonomous system number belongs to routing-protocol configuration, not to defining a logical unit; the unit needs a unit number and an IP address for routing. It is tempting because BGP runs over interfaces, and it would be correct when configuring an external BGP peer session.

Chassis cluster redundancy group ID

Why it fails: A redundancy group ID applies to chassis cluster failover, not to logical unit definition; IP routing needs a unit number and an address. It is tempting because cluster configuration references interfaces, and it would be correct when assigning an interface to a redundancy group for failover.

MAC address override

Why it fails: A MAC address override is optional and only alters the source MAC on the logical unit; IP routing requires a logical unit number and an IP address. It is tempting because MAC settings appear in interface configuration, and it would be correct when the upstream device expects a specific MAC.

All matching rule-sets are applied in parallel, which can cause translation conflicts.

Why it fails: Junos evaluates destination NAT rule-sets sequentially in the order they are referenced in the rule-set list, stopping at the first match, so parallel application never occurs. It is tempting because security policies do evaluate multiple matching rules, but NAT translation commits to a single rule-set before policy lookup.

Rule-sets are evaluated based on the most specific destination IP address match across all rule-sets simultaneously.

Why it fails: Junos evaluates destination NAT rule-sets one at a time in configured order, not by comparing destination IP specificity across all rule-sets simultaneously. It is tempting because longest-prefix match does govern route selection, and would be correct if NAT rule-sets were evaluated like routing entries.

Destination NAT rule-sets are evaluated alphabetically by rule-set name.

Why it fails: Junos processes destination NAT rule-sets in the order they appear in the rule-set reference list, not alphabetically by name, so renaming cannot alter which rule-set translates the packet. It is tempting because alphabetical ordering is a familiar convention, and would apply if the device sorted rule-sets by name.

Disable the security ALG for TCP streams to allow raw fragmentation forwarding.

Why it fails: TCP ALGs rewrite sequence and acknowledgement numbers for NAT; disabling them breaks stateful inspection and does not restore the dropped ICMP 'Fragmentation Needed' packets. PMTUD needs those ICMP errors permitted through the flow. Disabling an ALG suits troubleshooting application-embedded addressing, not MTU discovery failures.

Configure a Destination NAT pool specifically for ICMP fragmentation packets.

Why it fails: Destination NAT translates the initial packet's destination address; ICMP error messages carry the embedded original header and are matched to the existing static NAT session, so a separate pool cannot apply. The real gap is that the ICMP error is dropped for lack of a session. A DNAT pool suits publishing an internal service.

Enable proxy-arp for all fragmented packet ranges on the static NAT interface.

Why it fails: Proxy-ARP resolves address mapping for NAT, not PMTUD. The dropped ICMP 'Fragmentation Needed' messages require permitting ICMP unreachable or enabling path-MTU handling on the SRX. Proxy-ARP is tempting because it relates to NAT reachability, but fragmentation ranges are unrelated to ARP resolution.

The routing table lacks a default route for static NAT reply packets.

Why it fails: Reply packets arrive on the untrusted interface and are matched against the existing session before any route lookup, so a missing default route cannot produce 'No session found'. A default route matters for outbound traffic lacking a specific destination entry.

Static NAT requires explicit source NAT pool definitions for all outbound connections.

Why it fails: Static NAT maps one private address to one public address without a pool, so no pool definition is required for replies to match the existing session. Pools belong to source NAT, which would be chosen when many internal hosts must share few public addresses.

Proxy ARP is not enabled for the internal server's private IP address.

Why it fails: Proxy ARP resolves the public NAT address to the SRX's MAC for inbound peers; it does not create or locate sessions. It would be the correct fix when external hosts cannot resolve the NAT IP's MAC on the same subnet.

It is evaluated before Destination NAT in the Junos processing pipeline.

Why it fails: Junos evaluates Destination NAT before Source NAT in the packet processing pipeline, so interface-based Source NAT runs after, not before. The option is tempting because NAT ordering matters when both are applied, but the stated sequence reverses the actual order.

It requires an explicit address pool containing at least 10 public IP addresses.

Why it fails: Interface-based Source NAT translates to the interface's own address, so no address pool is configured at all; that is the defining difference from pool-based NAT. The option is tempting because pool-based source NAT does require an explicit pool, but interface-based NAT needs none.

It requires Proxy ARP configured on all internal interfaces.

Why it fails: Proxy ARP is needed for static NAT or pool-based NAT where the router answers for translated addresses, not for interface-based Source NAT, which uses the interface's own IP. The option is tempting because Proxy ARP appears in many NAT designs, but it is not required here.

Interface-based NAT is overriding the pool-based NAT configuration due to a rule-set ordering conflict.

Why it fails: Interface-based NAT translates to the egress interface address, so it cannot exhaust a configured pool's ports. It is tempting because rule ordering genuinely decides which NAT rule matches first, making it correct when overlapping rule-sets produce unexpected translations, but the trace names pool port exhaustion specifically.

The SRX device has reached its maximum global session limit across all security contexts.

Why it fails: A global session ceiling would report a session-limit error, not a pool port shortage, and would affect all traffic rather than one NAT pool. It is tempting because platform-wide limits do cause drops, making it the right diagnosis when aggregate sessions plateau, but here only a fraction of pool addresses is used.

Proxy ARP is blocking additional port allocation from the upstream gateway.

Why it fails: Proxy ARP governs Layer 2 address resolution and has no role in port allocation, so it cannot cause a pool exhaustion error while addresses remain free. The real cause is that all ports on the utilised pool addresses are consumed, or the pool is configured with too few ports per IP. Proxy ARP would be relevant when hosts must resolve addresses across subnets.

Proxy ARP is rate-limiting the ARP reply frequency for source NAT public IPs.

Why it fails: Proxy ARP governs address resolution for NAT pool IPs; it does not allocate ports, so it cannot produce a port-limit error. It is tempting because Proxy ARP is genuinely configured on SRX interfaces for NAT, and it would be the right answer if users reported ARP resolution failures rather than port exhaustion.

The SRX control plane CPU is throttling NAT session creation due to security policy evaluation lag.

Why it fails: Control-plane CPU throttling would slow session setup, but the traceoption explicitly reports port allocation failure, a dataplane PAT resource limit. It is tempting because CPU lag does cause intermittent drops, and it would be correct if traceoptions showed policy evaluation or session creation delays instead.

Destination NAT rules are consuming source NAT pool ports.

Why it fails: Destination NAT translates inbound traffic and does not draw from the source NAT pool's port range, so it cannot exhaust those ports. It is tempting because both are NAT features on the same device, and it would be correct if inbound destination NAT sessions were consuming a shared translation resource.

show security policies

Why it fails: This command displays policy configuration and does not report resource usage or drop counters. It cannot show whether the device is running short on sessions or other flow resources, so it does not address the suspicion that a resource limitation is the cause of the drops.

show interfaces extensive

Why it fails: This command shows interface-level statistics and errors, which can indicate physical or link issues but not flow resource exhaustion. It is useful for ruling out interface problems, but it does not report security flow resource usage or drops caused by session table limits.

show security zones

Why it fails: This command lists zone configuration and interface bindings and carries no resource or drop statistics. It cannot help determine whether flow resources are exhausted, so it is not the right tool for investigating resource-related packet drops.

Enable packet capture on all interfaces simultaneously and analyze the resulting capture files.

Why it fails: Enabling packet capture on all interfaces is resource-intensive and can affect device performance, and it captures packet contents rather than internal flow processing decisions. While packet captures can show whether packets arrive and leave, they do not directly reveal policy evaluation or session creation logic. In this scenario, this approach is excessive and does not efficiently identify why the session is not being created.

Run 'show security flow session' repeatedly and compare the outputs over time.

Why it fails: The 'show security flow session' command lists existing sessions, so if the session is not being created, it will not appear in the output. Repeatedly checking the session table does not explain why session creation failed. In this scenario, this approach cannot reveal the drop reason or policy decision, making it ineffective for diagnosing the missing session.

Set the security policy to log at session close and then inspect the traffic log.

Why it fails: Session close logging records information about sessions that were established and then closed, so it does not help when the session never gets created. If traffic is denied before session creation, session close logs will not be generated for that flow. In this scenario, this approach would not capture the cause of the failure and could lead the administrator to overlook the actual drop reason.

Destination NAT automatically performs source NAT using the egress interface address, which is why the server sees the client IP.

Why it fails: Destination NAT does not automatically apply source NAT. Junos OS treats destination NAT and source NAT as independent rule types; each must be explicitly configured. Without an explicit source NAT rule, the original source IP is retained. The server seeing the client IP is the expected result of destination NAT alone, not evidence of automatic source NAT.

The SRX is configured in transparent mode, which prevents source NAT from modifying packet headers.

Why it fails: Transparent mode affects how the device forwards traffic and performs bridging, but it does not inherently prevent NAT. If the SRX were in transparent mode, destination NAT might still function depending on configuration. However, the scenario describes normal routed operation with inbound HTTP redirection, not transparent mode. The absence of source NAT is due to missing source NAT configuration, not the operating mode.

The security policy is blocking source NAT translation, so the packet retains the original source address.

Why it fails: Security policies control whether traffic is permitted or denied; they do not enable or disable source NAT translation. Source NAT is governed by NAT rule configuration, not by policy action. Even with a permit policy, if no source NAT rule matches, the source IP remains unchanged. The policy is not the cause of the observed behavior.