Courseiva

CCNA Troubleshoot Questions

31 questions · Troubleshoot topic · All types, answers revealed

Practice these questionsExam hubAll questions
1
MCQmedium

A company is experiencing intermittent connectivity issues between two branch offices connected via an IPSec tunnel. Users report that they can access resources for a few minutes, then lose connectivity, and after a short time it comes back. Which troubleshooting step should be taken first?

A.Check the traffic logs for any denial events
B.Check the IPSec tunnel status and IKE/IPSEC SA rekey timers
C.Reboot the firewall to clear any stale sessions
D.Verify the routing table on both firewalls
AnswerB

Intermittent drops that recover after minutes typically indicate IKE or IPSec security association rekeying failures or mismatched lifetimes. Checking tunnel status and rekey timers first confirms whether SAs expire and fail to renegotiate, directly addressing the recurring loss of connectivity described.

Why this answer

The intermittent connectivity pattern (works for a few minutes, drops, then recovers) strongly indicates a phase 2 (IPsec SA) rekey failure. When the IPsec SA lifetime expires and the rekey fails, traffic stops until the SA is re-established, causing the described symptoms. Checking the IKE/IPsec SA rekey timers is the first logical step because it directly addresses the most likely root cause without introducing unnecessary changes.

Exam trap

The trap here is that candidates often jump to routing or security rule checks, but the periodic nature of the outage is a classic symptom of IPsec SA rekey failure, not a routing or policy issue.

How to eliminate wrong answers

Option A is wrong because traffic logs showing denial events would indicate persistent blocking (e.g., by security rules), not the periodic connectivity pattern described; intermittent rekey failures do not generate consistent denial log entries. Option C is wrong because rebooting the firewall is a disruptive, non-diagnostic step that clears all sessions and logs, potentially destroying evidence of the rekey failure and delaying resolution. Option D is wrong because verifying the routing table checks for static or dynamic route stability, but routing is typically stable in a site-to-site VPN; the periodic nature of the issue points to a VPN rekey problem, not a routing change.

Practice this question →
2
Multi-Selecthard

A Palo Alto Networks firewall administrator is troubleshooting why a session was terminated with the flag 'tcp-rst-from-client'. The administrator wants to identify possible causes for this termination flag. Which two factors can cause a session to be terminated with 'tcp-rst-from-client'? (Choose two.)

Select 2 answers
A.The client application was closed abruptly, causing the operating system to send a RST.
B.The firewall's security policy blocked the traffic, causing the client to send a RST.
C.The client's TCP window size was reduced to zero, triggering a RST from the client.
D.The client's TCP stack received a SYN-ACK for a connection that it did not initiate, prompting a RST.
E.The client received a packet that was out of order and sent a RST in response.
AnswersA, D

When a client application is closed abruptly (e.g., killed via Task Manager), the operating system may send a TCP RST to tear down the connection instead of a normal FIN. This results in a session termination with 'tcp-rst-from-client'. This is a common cause and should be considered when troubleshooting such flags.

Why this answer

The 'tcp-rst-from-client' flag indicates that the client sent a TCP RST packet. Common causes include the client application being closed abruptly, leading the OS to send a RST, or the client receiving a SYN-ACK for a connection it did not initiate, which triggers a RST. Other options like out-of-order packets or zero window do not cause RSTs.

Security policy blocks would result in a different flag. Therefore, the correct factors are abrupt application closure and unexpected SYN-ACK.

Exam trap

The trap here is assuming that any abnormal termination involves a RST, when in fact RSTs are specific to certain TCP state violations or application closures.

Practice this question →
3
MCQmedium

Refer to the exhibit. A user at 10.1.1.10 is trying to connect to a web server at 203.0.113.5 on port 443. The session shows 'State: DROP' with reason 'policy-deny'. However, the administrator has a security policy rule that allows SSL traffic from the source zone to the destination zone. What is the most likely cause of the drop?

A.The source NAT rule is missing, so the private IP cannot reach the internet.
B.The security policy rule that allows SSL is in a different rulebase or zone than the traffic.
C.The SSL application is not correctly identified because the traffic is encrypted.
D.The firewall is configured to block SSL sessions that use weak ciphers.
AnswerB

A policy-deny drop despite an apparent allow rule indicates the matching rule sits in a different rulebase or zone context than the traffic traversing the firewall. Zone and rulebase membership determine which rules are evaluated for a given session.

Why this answer

The session shows 'policy-deny' with a DROP state, which indicates that the traffic matched a deny rule or did not match any allow rule in the security policy. Even though the administrator believes an SSL allow rule exists, the most common cause is that the rule is in a different rulebase (e.g., pre-rulebase or post-rulebase) or the traffic is traversing a different zone pair than the one the rule applies to. The firewall evaluates rules in a specific order (pre-rulebase, then rulebase, then post-rulebase), and if the rule is not in the correct location for the traffic's ingress and egress zones, it will not be matched, resulting in a policy-deny drop.

Exam trap

The trap here is that candidates assume a security policy rule exists globally, but the PCNSE exam tests the understanding that rules are zone-specific and rulebase-specific, so a rule in the wrong zone pair or rulebase will not be matched, leading to a policy-deny drop.

How to eliminate wrong answers

Option A is wrong because a missing source NAT rule would cause a different symptom: the session would show a 'nat-ip-alloc' failure or a 'no-route' drop, not a 'policy-deny' drop. Option C is wrong because the firewall can still match a security policy rule based on the destination port (443) and IP addresses even if the application is encrypted; SSL decryption is not required for policy matching. Option D is wrong because blocking weak ciphers is a function of SSL decryption profiles or SSL Forward Proxy settings, not a direct cause of a 'policy-deny' drop; such a block would result in a 'decrypt' or 'ssl' related drop reason, not 'policy-deny'.

Practice this question →
4
MCQeasy

A SOC analyst reports that a critical security policy rule denying traffic from the 'Untrust' zone to the 'DMZ' zone is not generating any traffic logs, even though the analyst sees a high volume of denied traffic in other tools. The administrator confirms that the rule is correctly configured to deny and that logging is enabled at the rule level. What is the most likely reason for the missing logs?

A.The 'Untrust' zone is not configured to log traffic, and zone-level logging overrides rule-level logging.
B.The security policy rule is not being matched because the traffic is being denied by a different rule or a default rule with logging disabled.
C.The firewall's log storage is full, so new logs are being dropped.
D.The firewall is in a high-availability active-passive pair, and logs are only generated on the active device.
AnswerB

If the traffic is not matching the specific deny rule, it could be denied by an earlier rule or the default interzone/intrazone rule, which may not have logging enabled. The default rules often do not log by default. This would explain why the analyst sees denied traffic elsewhere but not from this rule. The administrator should check the session browser or traffic logs to see which rule is actually denying the traffic.

Why this answer

The most likely reason is that the traffic is being denied by a different rule, such as a default rule or an earlier rule in the policy, which does not have logging enabled. The administrator should verify which rule is actually matching the traffic by checking the session browser or traffic logs. This is a common oversight when a specific deny rule does not seem to be logging, despite being configured to do so.

Exam trap

The trap here is assuming that because a rule is configured to deny and log, it must be the rule that is matching the traffic, when in fact another rule or default rule could be denying the traffic without logging.

Practice this question →
5
MCQhard

A security administrator is investigating why a session was terminated with the flag 'tcp-rst-from-server' in the traffic logs. The administrator has confirmed that the server is reachable and responding to pings. Which of the following is the most likely cause for this session termination?

A.The server's TCP window size was set to zero, causing the firewall to send a RST.
B.The firewall's security policy blocked the traffic, causing the server to send a RST.
C.The server's operating system crashed and rebooted, sending a RST upon recovery.
D.The server's TCP stack sent a RST packet because the application was not listening on the requested port.
AnswerD

When a server receives a TCP SYN for a port where no application is listening, it typically responds with a RST packet. This results in a session termination with 'tcp-rst-from-server'. The server being reachable via ping only confirms IP connectivity, not that the specific service is running. Therefore, the most likely cause is that the application is not listening on the port, leading to the RST.

Why this answer

A session terminated with 'tcp-rst-from-server' indicates that the server sent a TCP RST packet. This commonly occurs when the server receives a connection attempt for a port where no service is listening. While the server may respond to ICMP pings, that does not guarantee the application is available.

Other causes like security policy blocks or zero window would produce different flags. Therefore, the correct answer is that the application is not listening on the port.

Exam trap

The trap here is equating basic IP reachability with application availability, overlooking that a RST often signals a closed port.

Practice this question →
6
MCQmedium

A network engineer is troubleshooting why a Palo Alto Networks firewall is not generating any traffic logs for sessions that match a security policy rule set to allow. The engineer confirms that the rule is hit and traffic passes successfully. Which of the following is the most likely reason for the absence of logs?

A.The log forwarding profile is misconfigured, preventing logs from being written to local storage.
B.The security policy rule does not have the 'Log at Session End' option enabled.
C.The traffic is being offloaded to hardware and thus bypasses logging.
D.The firewall's log storage is full and is dropping new logs.
AnswerB

By default, security policy rules do not log traffic at session end unless explicitly configured. Enabling 'Log at Session End' ensures that a traffic log is generated when the session terminates. Since the rule is hit and traffic passes, the absence of logs is likely because this option is not selected. This is a common configuration oversight in troubleshooting log generation issues.

Why this answer

The absence of traffic logs for allowed sessions is typically due to the security policy rule not having the 'Log at Session End' option enabled. Even if the rule is hit and traffic passes, without this setting, the firewall will not generate a traffic log. Other potential causes like log storage issues or offloading would have broader effects or different symptoms.

Therefore, checking the rule's logging configuration is the first step.

Exam trap

The trap here is assuming that all allowed traffic is automatically logged, when in fact logging must be explicitly enabled per rule.

Practice this question →
7
MCQeasy

A user reports intermittent connectivity to a database server through the firewall. The session table shows active sessions, but the user experiences timeouts. What is the most likely cause?

A.DNS resolution failure
B.Asymmetric routing
C.Security policy configured with service 'any'
D.Incomplete TCP three-way handshake
AnswerB

Asymmetric routing causes return traffic to bypass the firewall, so it never sees the full session and drops packets mid-flow. Sessions appear active in the table, yet the user times out, matching the intermittent connectivity symptom described.

Why this answer

Asymmetric routing causes the firewall to see only one direction of a TCP session, leading to session timeouts despite active session entries. When traffic from the client to the database server traverses one firewall and return traffic takes a different path, the firewall cannot properly track the TCP state, resulting in dropped packets and intermittent connectivity.

Exam trap

The trap here is that candidates see 'active sessions' in the table and assume the firewall is working correctly, overlooking that asymmetric routing can leave stale entries while actual data flow is disrupted.

How to eliminate wrong answers

Option A is wrong because DNS resolution failure would prevent the initial connection entirely, not cause intermittent timeouts with active sessions in the table. Option C is wrong because a security policy with service 'any' would allow all traffic, not cause timeouts; it might increase security risk but does not disrupt established sessions. Option D is wrong because an incomplete TCP three-way handshake would prevent session establishment, not cause intermittent timeouts after sessions are already active in the table.

Practice this question →
8
MCQeasy

A network administrator is troubleshooting a Palo Alto Networks firewall and needs to view the current sessions in real-time to identify which application is consuming the most bandwidth. Which command should the administrator use?

A.show running resource-monitor
B.show system statistics
C.show session all
D.show interface all
AnswerC

The 'show session all' command displays all current sessions on the firewall, including details such as source, destination, application, and bytes transferred. This allows the administrator to identify which application is consuming the most bandwidth by sorting or filtering the output. It is the primary command for real-time session monitoring.

Why this answer

To view current sessions and identify bandwidth-consuming applications, the 'show session all' command is the most direct method. It lists all active sessions with details including application and byte counts. Other commands like 'show running resource-monitor' or 'show system statistics' provide aggregate data but not per-session detail. 'show interface all' shows interface-level statistics, not application breakdown.

Thus, 'show session all' is the correct choice.

Exam trap

The trap here is confusing aggregate system statistics with detailed session information, leading to commands that lack application-level visibility.

Practice this question →
9
MCQmedium

A company has two Palo Alto Networks firewalls in an active/passive high availability pair. The firewalls are configured with a virtual IP (VIP) for the internal network. Recently, the passive firewall was upgraded to a new PAN-OS version. After the upgrade, the active firewall is still running the old version. The administrator wants to perform a failover to make the upgraded firewall active. However, when the administrator attempts to manually failover, the new passive firewall does not become active. The HA synchronization status shows 'synchronized' but the preemption is disabled. The administrator checks the HA configuration and finds that the peer's version is not compatible. What should the administrator do to successfully failover to the upgraded firewall?

A.Disable HA, then reconfigure HA on both firewalls
B.Upgrade the active firewall to the same PAN-OS version as the passive firewall
C.Force the failover via the CLI using 'request high-availability state suspend' on the active firewall
D.Downgrade the passive firewall back to the old version
AnswerB

PAN-OS requires both HA peers to run identical versions for failover; the incompatible peer version blocks the passive firewall from taking over. Upgrading the active firewall to match restores version parity, satisfying the compatibility constraint so failover can proceed.

Why this answer

PAN-OS requires both firewalls in an active/passive HA pair to run the same major version to form a compatible HA connection. Even if synchronization status shows 'synchronized', the version mismatch prevents failover from succeeding. Upgrading the active firewall to match the passive firewall's version restores version compatibility and allows the failover to proceed.

Exam trap

The trap here is that candidates assume 'synchronized' status means HA is fully functional and failover will work, but they overlook that version compatibility is a prerequisite for stateful failover, not just configuration sync.

How to eliminate wrong answers

Option A is wrong because disabling and reconfiguring HA does not address the root cause—the version mismatch—and would cause unnecessary downtime and configuration loss. Option C is wrong because the 'request high-availability state suspend' command on the active firewall would force it to suspend, but the passive firewall still cannot become active due to the incompatible PAN-OS version, so failover would fail. Option D is wrong because downgrading the passive firewall back to the old version would revert the upgrade, defeating the purpose of making the upgraded firewall active, and is not a best practice for maintaining security and feature updates.

Practice this question →
10
MCQmedium

A network engineer is troubleshooting why a Palo Alto Networks firewall is not decrypting SSH traffic even though an SSL Forward Proxy decryption policy is configured for the internal zone. The engineer confirms that the SSH traffic matches the decryption policy and that the forward trust and untrust certificates are installed and valid. What is the most likely reason the SSH traffic is not being decrypted?

A.The decryption policy is not matching because the SSH application is not recognized due to encryption.
B.SSL Forward Proxy decryption does not support SSH; SSH decryption requires SSH Proxy.
C.The decryption policy is not applied because the SSH traffic is using a non-standard port.
D.The forward trust certificate is not trusted by the SSH client, so the firewall bypasses decryption.
AnswerB

SSH is not an SSL/TLS-based protocol, so SSL Forward Proxy cannot decrypt it. Palo Alto Networks firewalls provide SSH Proxy to decrypt and inspect SSH traffic. This requires a separate SSH Proxy decryption policy and a forward trust certificate. Since the engineer only configured SSL Forward Proxy, the SSH traffic remains encrypted and is not decrypted.

Why this answer

SSH is not an SSL/TLS protocol, so SSL Forward Proxy cannot decrypt it. Palo Alto Networks firewalls use SSH Proxy to decrypt and inspect SSH traffic, which requires a separate decryption policy and configuration. Since only SSL Forward Proxy is configured, the SSH traffic remains encrypted even if the policy matches.

The correct solution is to configure SSH Proxy decryption for the SSH traffic.

Exam trap

The trap here is assuming that SSL Forward Proxy can decrypt any encrypted traffic, including SSH, without recognizing that SSH requires a distinct SSH Proxy decryption policy.

Practice this question →
11
MCQhard

Refer to the exhibit. The traffic log shows a drop event from source IP 203.0.113.10 to destination 10.1.1.200 on port 443. The rule matched is 'deny-rule'. What is the most likely reason for this drop?

A.The traffic matched a security rule that explicitly denies it
B.A threat prevention profile detected and blocked the session
C.The traffic was blocked because the application is not allowed
D.The destination URL is categorized as prohibited
AnswerA

The log names 'deny-rule' as the matched rule, so the drop results from explicit policy denial rather than an implicit default or threat inspection. Traffic matching that rule is discarded, satisfying the stem's requirement to explain the drop event from 203.0.113.10 to 10.1.1.200 on port 443.

Why this answer

The traffic log explicitly states that the rule matched is 'deny-rule'. In Palo Alto Networks firewalls, when a security rule is configured with an action of 'Deny', any traffic matching that rule is dropped and logged with a 'deny' action. Since the log shows a drop event and the matched rule is 'deny-rule', the most direct and likely reason is that the traffic was explicitly denied by this security rule, not by any additional security profiles or external factors.

Exam trap

The trap here is that candidates may confuse a security rule's 'deny' action with a block caused by a security profile (like Threat Prevention or URL Filtering), but the log explicitly shows the rule matched is 'deny-rule', indicating the drop is from the rule itself, not from any profile-based inspection.

How to eliminate wrong answers

Option B is wrong because a threat prevention profile blocking a session would be logged with a different action (e.g., 'reset-both' or 'drop') and would reference a specific threat ID or vulnerability signature, not simply show a rule match of 'deny-rule'. Option C is wrong because if the application were not allowed, the firewall would typically log an 'application not allowed' or 'deny' action with a different rule match, but the log explicitly shows the rule 'deny-rule' as the matched rule, indicating the deny is due to the rule itself, not an application-based policy. Option D is wrong because URL filtering blocks would be logged with a URL filtering profile action (e.g., 'block' or 'override') and would reference a URL category, not simply show a rule match of 'deny-rule'; the log does not indicate any URL filtering profile involvement.

Practice this question →
12
Multi-Selecthard

Which THREE are required for a successful firewall-to-firewall IPSec VPN tunnel? (Choose three.)

Select 3 answers
A.Matching IKE version and encryption algorithms
B.Same firewall model
C.Same certificate authority
D.Matching proxy IDs (local/remote subnets)
E.Matching pre-shared keys or certificates
AnswersA, D, E

Matching IKE version and encryption algorithms is mandatory because both peers must negotiate identical Phase 1 and Phase 2 proposals; any mismatch in IKEv1 versus IKEv2, encryption, hashing, authentication or Diffie-Hellman group causes the security association negotiation to fail, preventing the tunnel from establishing.

Why this answer

Option A is correct because both peers must negotiate a compatible IKE version (IKEv1 or IKEv2) and agree on matching Phase 1/Phase 2 encryption, hash, authentication, and DH group algorithms, otherwise the ISAKMP/IPSec SA negotiation fails. Option D is correct because the proxy IDs (local and remote subnet selectors) must mirror each other on both firewalls; if the local subnet on one side does not match the remote subnet on the other, the tunnel will not establish or will fail to pass traffic. Option E is correct because authentication requires matching pre-shared keys or mutually trusted certificates, and a mismatch in PSK or certificate trust causes Phase 1 authentication to fail.

Option B is not required because IPSec is a standards-based protocol and interoperates between different firewall vendors and models. Option C is not required because a shared certificate authority is only needed when using certificate-based authentication; PSK authentication works without any CA, and even with certificates the requirement is mutual trust, not necessarily the same CA.

Exam trap

The trap here is that candidates often assume hardware or CA compatibility is required, but the PCNSE exam tests that only IKE parameters, authentication credentials, and proxy IDs must match—not the firewall model or a shared CA.

Practice this question →
13
MCQhard

A network security engineer is troubleshooting why a user's session to a SaaS application is being decrypted by SSL Forward Proxy but then immediately reset. The engineer checks the session details and sees the session end reason as 'tcp-rst-from-server'. Packet capture on the firewall shows that the server is sending a TCP RST after the client sends a TLS Client Hello. The firewall's decryption profile is configured to block sessions with untrusted issuers. What is the most likely cause of the reset?

A.The server is rejecting the connection because the SNI in the Client Hello does not match the server's expected hostname, or the server requires mutual TLS authentication.
B.The firewall's forward trust certificate is not trusted by the client, causing the client to reset the connection.
C.The server is using a self-signed certificate that is not trusted by the firewall's forward trust certificate.
D.The server is configured to require TLS 1.3, but the firewall's decryption profile is set to only allow TLS 1.2, causing the server to reset the connection.
AnswerA

When SSL Forward Proxy decrypts traffic, it generates a new Client Hello to the server. If the server expects a specific SNI that matches its certificate, or if it requires client certificate authentication (mutual TLS), the server may reject the connection with a TCP RST. This is a common issue when decryption interferes with server-side validation. The session end reason 'tcp-rst-from-server' confirms the server initiated the reset.

Why this answer

The correct answer is that the server is rejecting the connection due to SNI mismatch or mutual TLS requirements. When SSL Forward Proxy decrypts, it acts as a man-in-the-middle, and the server may see a different SNI or lack a client certificate, causing it to reset the connection. This is consistent with the observed 'tcp-rst-from-server' and the server sending a RST after receiving the Client Hello.

Exam trap

The trap here is assuming that any reset during SSL decryption is caused by certificate trust issues on the client or firewall side, when in fact the server may be rejecting the connection due to decryption-induced changes in the TLS handshake.

Practice this question →
14
MCQeasy

A network engineer needs to verify that a specific security rule is being hit by traffic. Which firewall log should be examined?

A.Configuration log
B.Traffic log
C.Threat log
D.System log
AnswerB

The traffic log records every session matched against security policy, including the rule name that permitted or denied it. Examining it confirms whether the specific security rule is being hit, directly satisfying the requirement to verify rule utilisation. Other logs, such as threat or URL filtering, only capture events after a rule already matched.

Why this answer

The Traffic log records every session that matches a security rule, including the rule ID, source/destination IPs, ports, and action (allow/deny). To verify that a specific security rule is being hit, you must examine the Traffic log, as it shows which rule processed each session. Configuration, Threat, and System logs do not contain per-session rule match data.

Exam trap

The trap here is that candidates confuse the Traffic log with the Threat log, thinking that only malicious traffic generates logs, but the Traffic log records all allowed and denied sessions regardless of threat status.

How to eliminate wrong answers

Option A is wrong because the Configuration log records administrative changes to the firewall (e.g., rule modifications, commits), not traffic matching events. Option C is wrong because the Threat log captures intrusion prevention, antivirus, or vulnerability exploits, not standard rule hits. Option D is wrong because the System log contains system-level events (e.g., HA state changes, disk errors, license expiry), not per-session rule match information.

Practice this question →
15
MCQeasy

A firewall administrator is troubleshooting a scenario where users cannot reach an internal web server. The security policy allows the traffic, and the server is reachable from other networks. What should the administrator check first?

A.The source and destination zones in the security policy
B.The firewall's DNS settings
C.The server's SSL certificate
D.The interface management profile
AnswerA

If zones in the security policy do not match the actual ingress and egress interfaces, the rule never matches and traffic is denied despite appearing to allow it. Confirming zone assignments is the first check.

Why this answer

The most common reason for traffic failing despite a security policy allowing it is a zone mismatch. In Palo Alto Networks firewalls, security policies are zone-based, meaning the source and destination zones in the policy must exactly match the ingress and egress zones of the traffic. If the administrator configured the policy with the wrong zones (e.g., using 'trust' for the source when the client is in 'dmz'), the traffic will be denied even if all other parameters (IP, port, application) are correct.

This is the first thing to verify because it directly controls whether the policy is evaluated for the session.

Exam trap

The trap here is that candidates often jump to checking DNS or certificates (common web server issues) instead of first verifying the fundamental zone-based policy matching, which is unique to Palo Alto Networks firewalls and a frequent cause of silent traffic drops.

How to eliminate wrong answers

Option B is wrong because DNS settings on the firewall affect only the firewall's own name resolution (e.g., for FQDN objects or external services), not the ability for users to reach an internal web server; client-side DNS resolution is independent of the firewall's DNS configuration. Option C is wrong because the server's SSL certificate is irrelevant to basic connectivity; certificate issues cause browser warnings or TLS handshake failures, not a complete inability to reach the server (which would be a network-layer problem). Option D is wrong because the interface management profile controls administrative access (e.g., HTTPS, SSH, ping) to the firewall interface itself, not the forwarding of user traffic through the firewall.

Practice this question →
16
MCQhard

A security administrator is troubleshooting why a user cannot access an internal server at 192.168.1.50 from the trust zone. The firewall is a PA-5220 running PAN-OS 10.2. The administrator checks the traffic log and sees that the session is allowed by a security policy rule. However, the user still cannot connect. The administrator runs 'show session all filter source 10.1.1.10 destination 192.168.1.50' and sees the session state as 'ACTIVE' but with 'tcp-rst-from-server' flag. What is the most likely cause?

A.The firewall is performing SSL decryption and the certificate is invalid.
B.The server is sending a TCP reset because it is not listening on the requested port.
C.The firewall is dropping the packets due to a security profile.
D.The session is being aged out due to timeout.
AnswerB

The 'tcp-rst-from-server' flag indicates that the server sent a TCP reset packet. This typically happens when the server receives a SYN for a port it is not listening on, or the service is not running. The firewall allowed the session, but the server rejected the connection. This is a common cause when the application on the server is down or the port is incorrect. The user cannot connect because the server actively refused the connection.

Why this answer

The 'tcp-rst-from-server' flag in the session details indicates that the server sent a TCP reset packet. This usually means the server is not listening on the requested port or the service is unavailable. The firewall allowed the session, but the server refused the connection.

The user cannot connect because the server actively rejected the SYN. Troubleshooting should focus on the server's service status and port configuration.

Exam trap

The trap here is assuming the firewall is blocking traffic because the user cannot connect, but the session flag clearly shows the server sent a reset, indicating a server-side issue.

Practice this question →
17
MCQeasy

A network engineer notices that traffic from a specific subnet is being dropped by the firewall. The traffic log shows 'drop' with reason 'policy deny'. The engineer checks the security policy and confirms there is an allow rule for that subnet. What should be checked next?

A.Check the application override.
B.Check the QoS policy.
C.Check the rule order and ensure the allow rule is above any deny rules.
D.Check the NAT policy for the traffic.
AnswerC

PAN-OS evaluates security rules top-down and stops at the first match. A deny rule positioned above the allow rule for that subnet matches first, producing the 'policy deny' drop despite the allow rule existing lower in the policy.

Why this answer

When a traffic log shows 'policy deny' despite an existing allow rule, the most common cause is rule order: Palo Alto firewalls evaluate security rules from top to bottom, and the first matching rule is applied. If a deny rule appears above the allow rule for the same subnet, the deny rule will match first and drop the traffic, making it essential to verify the rule sequence.

Exam trap

The common mistake is assuming that if an allow rule exists for the subnet, it will always be applied, ignoring that Palo Alto firewalls evaluate rules top-down and a higher-priority deny rule can preempt the allow rule.

How to eliminate wrong answers

Option A is wrong because application override is used to bypass App-ID for specific traffic, not to resolve policy deny issues caused by rule order; it would not change the matching behavior of security rules. Option B is wrong because QoS policy controls bandwidth allocation and prioritization, not access control; a QoS misconfiguration would not cause a 'policy deny' log entry. Option D is wrong because NAT policy is processed after security policy matching; if traffic is denied by security policy, it never reaches the NAT stage, so checking NAT would not address the deny reason.

Practice this question →
18
Multi-Selecthard

Which THREE components should be verified when troubleshooting a site-to-site IPSec VPN that is not coming up?

Select 3 answers
A.Zone protection profile on the untrust zone
B.Interface management profile on the external interface
C.Pre-shared key configuration on both ends
D.Peer IP address in the tunnel interface configuration
E.IKE version (v1 vs v2) compatibility
AnswersC, D, E

A mismatched pre-shared key causes IKE phase 1 authentication to fail, so the tunnel never negotiates. Verifying identical keys on both peers satisfies the stem's requirement to check components preventing the IPSec VPN from coming up, since the pre-shared key must match exactly on each end.

Why this answer

When a site-to-site IPSec VPN fails to establish, the IKE Phase 1 negotiation is the first thing to verify, and option C (pre-shared key configuration on both ends) is critical because a mismatched PSK causes IKE authentication to fail immediately. Option D (peer IP address in the tunnel interface configuration) is correct because the local device must reference the correct remote peer's public IP as the IKE gateway; a wrong or unreachable peer IP prevents any IKE exchange from starting. Option E (IKE version v1 vs v2 compatibility) is correct because both peers must agree on IKEv1 or IKEv2; a version mismatch means the devices cannot negotiate Phase 1 at all.

Options A and B are not part of the core IPSec VPN bring-up path: a zone protection profile (A) affects flood/scan protection on the untrust zone and does not govern tunnel negotiation, and an interface management profile (B) controls which management services (ping, SSH, HTTPS, etc.) are permitted on the interface, which is unrelated to IPSec tunnel establishment.

Exam trap

The trap here is that candidates often confuse zone protection profiles or interface management profiles with VPN-related security settings, but these profiles only affect data-plane or management-plane traffic, not the control-plane IKE negotiation required for tunnel establishment.

Practice this question →
19
MCQmedium

During a troubleshooting session, a user reports that they cannot access an internal web server through the firewall's public IP. The firewall is configured with destination NAT. The engineer checks the NAT policy and sees the rule is active. What should be the next step to verify the NAT is functioning correctly?

A.Check the session table to see if the NAT translation is occurring.
B.Check the application dependency.
C.Check the security policy for the post-NAT zone.
D.Check the routing table for the destination.
AnswerA

Destination NAT rewrites the packet header, so the session table is the authoritative record of whether translation actually occurred. Inspecting it confirms the public IP maps to the internal server and that traffic is matching the active rule, isolating NAT from policy or routing faults.

Why this answer

Checking the session table (e.g., using 'show session all' or 'show session id <id>') directly confirms whether the destination NAT (DNAT) translation is being applied to the traffic. If the session shows the original destination IP being translated to the internal server's IP, the NAT rule is functioning; if not, the issue lies elsewhere (e.g., policy order, matching conditions). This is the most immediate and definitive verification step in a Palo Alto Networks firewall.

Exam trap

The trap here is that candidates often jump to checking security policies or routing first, forgetting that the session table provides the most direct evidence of whether the NAT translation is actually being applied to the traffic.

How to eliminate wrong answers

Option B is wrong because application dependency checks are relevant for App-ID or SSL decryption issues, not for verifying whether a NAT translation is occurring. Option C is wrong because checking the security policy for the post-NAT zone is a subsequent step after confirming NAT is working; the security policy uses the post-NAT zone, but verifying NAT itself requires looking at the session table first. Option D is wrong because checking the routing table for the destination is relevant for routing issues (e.g., next-hop reachability), but does not confirm whether the NAT translation is actually being performed on the traffic.

Practice this question →
20
MCQeasy

A network administrator wants to verify if a specific internal IP address (10.1.1.100) is being translated to a public IP when accessing the internet. Which CLI command should be used?

A.show running nat-policy
B.show session all filter source 10.1.1.100
C.show nat rule
D.show address 10.1.1.100
AnswerB

`show session all filter source 10.1.1.100` queries the session table for entries matching that source address, revealing the NAT translation applied to each flow. Because Palo Alto Networks firewalls perform NAT through session-based policy evaluation, the session table holds the source and destination translation details, directly confirming whether 10.1.1.100 is translated to a public IP.

Why this answer

The 'show session all filter source 10.1.1.100' command displays active sessions in the firewall's session table, including the source IP, destination IP, and the translated (NAT) IP addresses. This allows the administrator to verify whether the internal IP 10.1.1.100 is being NATed to a public IP when accessing the internet, as the session table shows both the pre-NAT and post-NAT source addresses.

Exam trap

The trap here is that candidates confuse viewing NAT policy configuration (which shows rules) with viewing active NAT translations (which requires session table inspection), leading them to pick 'show running nat-policy' instead of the session-based command.

How to eliminate wrong answers

Option A is wrong because 'show running nat-policy' displays the configured NAT policy rules, not the active translations or sessions; it shows what should happen, not what is currently happening. Option C is wrong because 'show nat rule' is not a valid CLI command on Palo Alto Networks firewalls; the correct command for viewing NAT rules is 'show running nat-policy' or 'show nat-policy'. Option D is wrong because 'show address 10.1.1.100' is not a valid command; the correct command to view address objects is 'show address' or 'show address-group', and it does not show translation or session information.

Practice this question →
21
MCQhard

An administrator is troubleshooting a situation where traffic from a specific application is being dropped by the firewall. The security policy allows the application. The firewall logs show the session is denied, and the reason is 'application mismatch'. What does this indicate?

A.The firewall's App-ID identified the traffic as a different application than the one specified in the rule
B.The application is not recognized by the firewall and is treated as unknown
C.The security rule is not configured to allow any application
D.The firewall's SSL decryption is misconfigured
AnswerA

App-ID inspects the session and identifies the actual application, which may differ from the one the rule specifies. An 'application mismatch' denial means the detected application does not match the rule's application, so the session is dropped. This satisfies the stem's constraint that the policy allows the expected application.

Why this answer

The 'application mismatch' log reason indicates that the firewall's App-ID engine identified the traffic as a different application than the one specified in the security rule. Even though the rule allows the application you intended, the actual traffic does not match that App-ID signature, so the session is denied. This is a common scenario when the application classification does not align with the rule's application object.

Exam trap

The trap here is that candidates often assume 'application mismatch' means the application is unknown or unsupported, but it specifically means the traffic was identified as a different application than what the rule expects, highlighting the importance of verifying App-ID results versus rule configuration.

How to eliminate wrong answers

Option B is wrong because 'application mismatch' is a specific denial reason that occurs when the traffic is recognized but as a different application, not when it is unknown (unknown traffic would show 'unknown-tcp' or 'incomplete' App-ID). Option C is wrong because the scenario explicitly states the security policy allows the application, so the rule is configured to allow an application; the issue is a mismatch, not a missing 'any' application. Option D is wrong because SSL decryption misconfiguration would cause decryption errors or 'ssl-decrypt' related drops, not an 'application mismatch' denial; App-ID can still match encrypted traffic based on metadata or SNI.

Practice this question →
22
MCQeasy

A firewall administrator is troubleshooting why a user is unable to access a website. The administrator checks the traffic logs and sees that the session was allowed by the security policy, but the application is identified as 'ssl' instead of 'web-browsing'. The website uses HTTPS on port 443. What is the most likely reason for the application being identified as 'ssl'?

A.The security policy rule is set to allow 'ssl' but not 'web-browsing', so the application is identified as 'ssl'.
B.The website uses a non-standard port for HTTPS, so the firewall cannot identify it as 'web-browsing'.
C.The firewall's application database is outdated and does not recognize 'web-browsing' over SSL.
D.The firewall is not configured to decrypt SSL traffic, so it cannot identify the application as 'web-browsing'.
AnswerD

Without SSL decryption, the firewall can only see the SSL handshake and cannot inspect the HTTP headers to identify the application as 'web-browsing'. The application will be identified as 'ssl' because it is encrypted. This is expected behavior when decryption is not enabled, and it does not necessarily mean the user cannot access the website.

Why this answer

The application is identified as 'ssl' because the traffic is encrypted and the firewall cannot inspect the HTTP headers without SSL decryption. To identify 'web-browsing', the firewall must decrypt the traffic. This is expected behavior when decryption is not configured.

The other options are less likely because the port is standard, the policy does not dictate application identification, and the database is not indicated as outdated.

Exam trap

The trap here is assuming that the firewall can always identify 'web-browsing' even without decryption, when in fact encrypted traffic is identified as 'ssl'.

Practice this question →
23
MCQhard

A firewall administrator is troubleshooting an issue where a PA-3260 is experiencing high dataplane CPU utilization. The administrator runs 'show running resource-monitor' and sees that the CPU is consistently above 90%. Which command should the administrator use to identify the top applications contributing to the high CPU usage?

A.show system resources
B.show running resource-monitor application
C.show session all filter application
D.show running resource-monitor ingress-backlogs
AnswerB

This command displays resource monitoring statistics per application, including CPU usage. It is specifically designed to show which applications are consuming the most resources, making it ideal for identifying the top applications contributing to high dataplane CPU. It provides a breakdown that helps pinpoint the cause.

Why this answer

The command 'show running resource-monitor application' provides per-application resource utilization, including CPU. This allows the administrator to see which applications are consuming the most dataplane CPU. Other commands like 'show system resources' give overall usage, and 'show session all filter application' lists sessions but not CPU impact.

The ingress-backlogs command is for queue monitoring, not CPU attribution.

Exam trap

The trap here is confusing overall system resource monitoring with per-application resource monitoring, which is needed to attribute CPU usage to specific applications.

Practice this question →
24
MCQeasy

A user reports that they cannot access a specific website. The firewall security policy allows web traffic. The administrator checks the traffic log and sees that the session is being denied due to a 'URL Filtering' block. What should the administrator do to allow access?

A.Disable URL filtering on the existing security rule
B.Check the user-ID mapping to ensure the user is authenticated
C.Create a new security rule allowing the user's IP to any
D.Add the URL to an allow list in the URL filtering profile
AnswerD

The traffic log shows the session denied by URL Filtering rather than the security policy, so the URL category is blocked in the URL filtering profile. Adding the specific URL to the allow list in that profile permits access while the security policy remains unchanged.

Why this answer

The traffic log explicitly indicates a 'URL Filtering' block, meaning the firewall's URL filtering profile is denying the request based on the URL category or specific URL. Adding the URL to an allow list within the URL filtering profile overrides the block, allowing access while keeping the security rule and other filtering policies intact. This approach preserves security controls for other traffic and avoids disabling URL filtering entirely.

Exam trap

The trap here is that candidates may assume disabling URL filtering entirely (Option A) is the quickest fix, but the PCNSE exam tests the understanding that URL filtering profiles should be modified granularly using allow/block lists rather than disabling the feature completely.

How to eliminate wrong answers

Option A is wrong because disabling URL filtering on the existing security rule would remove all URL-based controls for that rule, potentially exposing the network to malicious or inappropriate websites, which is an overreaction to a single blocked URL. Option B is wrong because the user-ID mapping is irrelevant to a URL filtering block; URL filtering decisions are based on the URL category or list, not user authentication status, and the traffic log already shows the session is denied due to URL filtering, not authentication. Option C is wrong because creating a new security rule allowing the user's IP to any would bypass all security policies, including URL filtering, but it is an insecure and overly permissive solution that ignores the specific URL filtering block and could allow unrestricted access to any destination.

Practice this question →
25
Multi-Selecteasy

Which TWO are valid methods to troubleshoot a firewall not passing traffic? (Choose two.)

Select 2 answers
A.Reboot the firewall
B.Change the interface IP address
C.Verify the security policy order
D.Check the session table for the traffic
E.Update the threat prevention signature
AnswersC, D

Verifying security policy order confirms that no earlier, broader rule is shadowing the intended permit, since PAN-OS evaluates rules top-down and stops at the first match. This directly satisfies the stem's troubleshooting requirement by ruling out misordering as the cause of dropped traffic.

Why this answer

Option C is correct because firewall policy is evaluated top-down, so a broader or more specific rule placed above the intended rule can shadow it and silently drop or block the traffic; verifying rule order confirms whether the matching permit rule is actually being reached. Option D is correct because the session table (e.g., 'show session all filter source x.x.x.x destination y.y.y.y' on Palo Alto, or 'conntrack -L'/'show conn' on other platforms) reveals whether a session was created, its state, and whether it was denied, which directly indicates where traffic is failing. Option A is not a troubleshooting method since rebooting only clears state temporarily and provides no diagnostic evidence of the root cause.

Option B is not valid because changing the interface IP address alters the configuration rather than diagnosing the existing forwarding or policy problem. Option E is not valid because updating threat prevention signatures addresses content inspection, not the basic forwarding or policy issue being investigated.

Exam trap

The trap here is that candidates often assume rebooting or updating signatures will fix traffic issues, but these actions do not address the most common causes like policy misordering or session state problems, which are directly verifiable through the session table and policy order review.

Practice this question →
26
Multi-Selecteasy

Which TWO commands can be used to check the status of an IPSec tunnel on a Palo Alto Networks firewall?

Select 2 answers
A.show system info
B.show vpn ike-sa
C.show routing route
D.show vpn ipsec-sa
E.show interface all
AnswersB, D

The show vpn ike-sa command displays Phase-1 IKE security associations, including peer addresses, state, and remaining lifetime. Inspecting it confirms whether the IKE tunnel itself is established, which is the required status check for an IPSec tunnel.

Why this answer

Option B, 'show vpn ike-sa', is correct because it displays the status of IKE Phase 1 security associations, which are the foundation of an IPSec tunnel and must be established before Phase 2 can come up. Option D, 'show vpn ipsec-sa', is correct because it shows the IPSec Phase 2 security associations, directly confirming whether the tunnel itself is active and passing traffic. Together these two commands let an administrator verify both phases of an IPSec VPN on a Palo Alto Networks firewall.

Option A, 'show system info', only reports general device information such as model, software version, and uptime, not tunnel state. Option C, 'show routing route', displays the routing table and cannot show IKE or IPSec SA status. Option E, 'show interface all', shows interface statistics and link state, which is unrelated to IPSec tunnel status.

Exam trap

The trap here is that candidates often confuse general network commands (like routing or interface status) with VPN-specific commands, assuming that a working route or interface implies a functional IPSec tunnel, when in fact the tunnel may be down due to IKE or IPSec SA failures.

Practice this question →
27
MCQeasy

Refer to the exhibit. A firewall system log contains a critical license expiration entry for URL Filtering. What will happen to URL Filtering functionality?

A.The firewall will stop passing traffic until the license is renewed.
B.URL Filtering will stop working immediately until a new license is installed.
C.URL Filtering will continue to use the last downloaded URL database but will not receive updates.
D.The firewall will automatically fall back to a basic URL category list.
AnswerC

An expired URL Filtering licence disables database updates only; the firewall retains the last downloaded URL database and continues enforcing it. This satisfies the scenario because filtering still functions, merely growing stale as new URLs are uncategorised.

Why this answer

When a URL Filtering license expires on a Palo Alto Networks firewall, the device does not immediately disable the feature. Instead, it continues to use the last downloaded URL database to categorize URLs, but it will no longer receive periodic database updates from the Palo Alto Networks update server. This ensures that existing traffic policies based on URL categories remain functional, though new or changed URLs may not be accurately categorized until the license is renewed.

Exam trap

A common misconception is that license expiration immediately disables the associated feature, but Palo Alto Networks firewalls are designed to continue using the last known good data to maintain operational continuity until the license is renewed.

How to eliminate wrong answers

Option A is wrong because the firewall does not stop passing all traffic; only the URL Filtering update mechanism is affected, and traffic continues to flow based on existing policies. Option B is wrong because URL Filtering does not stop working immediately; the last downloaded database remains active and continues to be used for URL categorization. Option D is wrong because the firewall does not automatically fall back to a basic URL category list; it retains the full, last-downloaded database without any automatic downgrade to a simpler list.

Practice this question →
28
MCQhard

An administrator is troubleshooting VPN tunnel flapping. The logs show multiple Phase 2 rekeys. The tunnel uses IKEv2 with pre-shared key. What is the most likely cause?

A.Mismatched IKE version.
B.Dead Peer Detection (DPD) interval too long.
C.The rekey time settings are too short.
D.Incorrect local or peer ID.
AnswerC

IKEv2 Phase 2 rekeys occur when the IPsec security association lifetime expires. Excessively short rekey timers force frequent renegotiation, and if either peer fails to complete it in time, the tunnel drops and re-establishes, producing flapping.

Why this answer

Frequent Phase 2 rekeys indicate that the IPsec security associations (SAs) are being renegotiated too often. With IKEv2, the rekey time settings (e.g., lifetime seconds or kilobytes) control how long a Phase 2 SA remains active before it must be refreshed. If these values are set too short, the tunnel will flap as SAs are constantly re-established, causing intermittent connectivity.

Exam trap

The trap here is that candidates often confuse rekey flapping with DPD or misconfiguration issues, but the specific log entry of 'multiple Phase 2 rekeys' directly points to the SA lifetime being too short, not to peer reachability or identity problems.

How to eliminate wrong answers

Option A is wrong because IKEv2 is explicitly specified in the scenario, and a mismatched IKE version would prevent Phase 2 establishment entirely, not cause flapping after initial setup. Option B is wrong because a DPD interval that is too long would delay detection of a dead peer, potentially causing the tunnel to stay up longer, not trigger frequent rekeys; a too-short DPD interval could cause false timeouts, but the logs show Phase 2 rekeys, not DPD-related failures. Option D is wrong because incorrect local or peer ID would typically cause authentication or identity validation failures during Phase 1 or Phase 2, leading to a complete failure to establish the tunnel, not repeated rekeys of an already-established SA.

Practice this question →
29
MCQeasy

A network administrator notices that traffic from a specific user to the internet is being blocked by the firewall. The user's IP is 10.1.1.100, and the destination is a public website. The security policy has a rule that allows traffic from subnet 10.1.1.0/24 to any. What is the first thing the administrator should verify?

A.Check the security policy rulebase order and matching
B.Verify the user-ID agent is mapping the IP correctly
C.Check the service configuration for the destination port
D.Check the NAT configuration for the user's subnet
AnswerA

Security policies are evaluated top-down, so a deny rule above the permit rule for 10.1.1.0/24 would block this user despite the allow existing. Verifying rulebase order and matching confirms which rule actually handles the session, satisfying the need to identify why permitted subnet traffic is dropped.

Why this answer

The first thing to verify is the security policy rulebase order and matching because Palo Alto Networks firewalls evaluate rules in a top-down order and apply the first matching rule. Even if a rule exists that allows traffic from subnet 10.1.1.0/24 to any, a preceding rule with a deny action or a more specific match could be blocking the traffic from 10.1.1.100. Checking rule order ensures that the intended allow rule is actually being hit before investigating other potential issues.

Exam trap

The trap here is that candidates often jump to NAT or service configuration issues, but the PCNSE exam emphasizes that rule order and first-match logic are the most common root cause of unexpected blocks, especially when a seemingly correct allow rule exists.

How to eliminate wrong answers

Option B is wrong because verifying the User-ID agent mapping is only relevant if the security policy uses user-based criteria (e.g., source user), but the rule in question is based on source IP (subnet 10.1.1.0/24), not user identity. Option C is wrong because checking the service configuration for the destination port is secondary; if the rule is not matched due to order, service configuration is irrelevant until the correct rule is identified. Option D is wrong because NAT configuration affects the translated IP address, not the pre-NAT source IP used for policy matching; the firewall applies security policy before NAT, so NAT issues would not cause the traffic to be blocked by a policy that matches the original source IP.

Practice this question →
30
MCQeasy

A firewall administrator is troubleshooting a connectivity issue where users cannot reach a web server. The administrator checks the traffic log and sees that the session is being denied by a security policy rule. The administrator verifies that the rule is correctly configured to deny the traffic. However, the administrator wants to see which rule is blocking the traffic. Which action should the administrator take?

A.Use the 'test security-policy-match' command with the source and destination IP addresses.
B.Check the system log for a policy deny message.
C.Run 'show session all filter source <user-ip>' and look at the 'rule' column.
D.Check the traffic log details for the session and look at the 'Rule' field.
AnswerD

The traffic log includes a 'Rule' field that specifies the name of the security policy rule that matched the session. By examining the log details, the administrator can identify exactly which rule denied the traffic. This is the most direct method. The log entry will also show the action taken. This is a fundamental troubleshooting step for policy-related issues.

Why this answer

The traffic log contains detailed information about each session, including the name of the security policy rule that matched. By viewing the log details, the administrator can see the 'Rule' field and identify the blocking rule. This is the standard method for determining which policy rule is affecting traffic.

Other commands like 'test security-policy-match' are for simulation, and session table output does not include rule names.

Exam trap

The trap here is using the session table or system logs to find the rule, but the rule name is only available in the traffic log details.

Practice this question →
31
MCQmedium

A firewall administrator is troubleshooting an issue where users behind a PA-3220 cannot access a public web server. The security policy allows the traffic. The administrator runs 'show session all filter source 10.1.1.50 destination 203.0.113.10' and sees a session with application 'incomplete' and no packets received from the server. Which tool should the administrator use to determine why the firewall is not receiving a response from the server?

A.Use the packet capture feature with a filter on the source and destination IP addresses to capture traffic on both ingress and egress interfaces.
B.Review the traffic logs filtered by the application 'incomplete' to see the session end reason.
C.Check the ARP table for the destination IP address to ensure the next-hop MAC address is resolved.
D.Run 'show counter global filter delta yes' to check for packet buffer drops.
AnswerA

Packet capture allows the administrator to see if the request is leaving the egress interface and whether any response is arriving on the ingress interface. This directly addresses the 'no packets received from server' symptom. By capturing on both interfaces, the administrator can determine if the firewall is dropping the packet or if the server is not responding.

Why this answer

The session shows application 'incomplete' and no packets received from the server, indicating the firewall may not be receiving a response. Packet capture on both ingress and egress interfaces will show if the request is sent and if any reply arrives, helping isolate whether the issue is with the firewall, network path, or server. Other tools like global counters or ARP checks do not provide the same level of detail for this specific flow.

Exam trap

The trap here is assuming that a session with application 'incomplete' always indicates a firewall drop, when it could simply mean the server is not responding or the return path is broken.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Troubleshoot questions.

Start 20-question session