Courseiva
Troubleshoot →hardMultiple Choice

PCNSE Troubleshoot Practice Question

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?

⚠ Common 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.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The server is sending a TCP reset because it is not listening on the requested port.

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.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    The firewall is performing SSL decryption and the certificate is invalid.

    Why it's wrong here

    SSL decryption issues would typically cause certificate errors or session failures, but not necessarily a 'tcp-rst-from-server' flag. If the firewall were decrypting, it might reset the connection if the certificate is invalid, but the flag would likely indicate the firewall as the source. The scenario does not mention SSL decryption. The reset flag from the server strongly suggests the server itself rejected the connection, not a decryption problem.

  • ✓

    The server is sending a TCP reset because it is not listening on the requested port.

    Why this is correct

    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.

  • ✗

    The firewall is dropping the packets due to a security profile.

    Why it's wrong here

    If a security profile were dropping packets, the session would likely be terminated or show a different flag, such as 'policy-deny' or 'threat'. The 'tcp-rst-from-server' flag specifically indicates the reset came from the server, not the firewall. Security profiles can reset connections, but the flag would typically be 'tcp-rst-from-client' or 'tcp-rst-from-server' if the reset is injected by the firewall? Actually, if the firewall injects a reset, the flag might be 'tcp-rst-from-server' if it spoofs the server, but that is less common. The most direct interpretation is that the server sent the reset.

  • ✗

    The session is being aged out due to timeout.

    Why it's wrong here

    Session aging would result in the session being removed from the session table, not showing 'ACTIVE' with a reset flag. The 'tcp-rst-from-server' flag is set when a reset is received, not when a session times out. Timeouts typically show as 'TIME_WAIT' or the session disappears. The user's inability to connect is due to the reset, not aging. Aging would not cause an immediate connection failure; it would affect long-idle sessions.

Visual reference

Source Router + ACL permit 10.0.0.0/8 deny any Server 10.0.0.5 ✓ 192.168.1.1 ✗ dropped ACLs evaluate top-down; first match wins — implicit deny all at end

About these practice questions

One of 319 original PCNSE practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written and reviewed by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

Last reviewed September 2026 · checked against the official Palo Alto Networks exam blueprint

This PCNSE practice question is part of Courseiva's free Palo Alto Networks certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PCNSE exam.