B. > set session tcp-reject-non-syn no
D. # set deviceconfig setting session tcp-reject-non-syn no

Explanation:
Palo Alto Networks firewalls, by default, perform stateful inspection. This means they expect to see the complete TCP three-way handshake (SYN, SYN-ACK, ACK) for a session to be established and traffic to be allowed. In an asymmetric routing environment, the firewall might see only one direction of the traffic, such as the SYN packet on the way out but not the SYN-ACK on the way back. When the firewall later sees an ACK or data packet for a session it doesn't recognize as established, it drops the packet with a "TCP non-SYN" reject log message.
To resolve this issue without changing the network's routing, you must disable this strict enforcement. This can be done using one of two methods:

1.Command Line Interface (CLI):
The command set deviceconfig setting session tcp-reject-non-syn no disables the rejection of non-SYN TCP packets. This is a global setting that affects all TCP sessions on the firewall. The command can be abbreviated as set session tcp-reject-non-syn no.
2.Web Interface (GUI):
This setting can also be configured in the GUI under Device > Setup > Session Settings. Here, you would uncheck the Reject Non-SYN TCP option.
The provided options B and D are simply different ways of expressing the correct CLI command. set session tcp-reject-non-syn no is the standard command, while # set deviceconfig setting session tcp-reject-non-syn no includes the full path and the # symbol, which is often used to denote a command run from a configuration mode. Both achieve the same result.

❌ Why the Other Options are Incorrect
A and C: Options A and C describe modifying Zone Protection Profiles. While these profiles are used to prevent certain types of attacks, they are not the correct place to handle asymmetric routing. The "Reject Non-syn-TCP" setting within a Zone Protection Profile is designed to prevent SYN floods and other packet-based attacks from non-SYN packets. It's a security feature that is a subset of the global session setting and is not intended to resolve asymmetric routing issues. The global session setting is the correct way to handle this persistent network architecture problem. Additionally, the "Asymmetric Path" setting in Zone Protection Profiles is related to path changes within a single session, not to a persistent asymmetric routing problem.

📚 Reference
This topic is a key part of the PCNSE exam's Troubleshooting domain. The documentation for Palo Alto Networks firewalls, specifically the sections on Session Settings and Troubleshooting Asymmetric Routing, provides detailed information on this configuration. The ability to use both the CLI and GUI to make these changes is an important skill tested on the exam.

D. Add a Zone Protection profile to the affected zones

Explanation:
A firewall administrator is investigating high packet buffer utilization on a Palo Alto Networks firewall, noting from threat logs that many flood attacks from a single source are being dropped. The administrator enabled packet buffer protection globally (under Device > Setup > Session > Packet Buffer Protection) to mitigate buffer overflow from such attacks, which deplete resources by overwhelming the data plane. However, high utilization persists, indicating that global settings alone are insufficient. The next step is to add a Zone Protection profile to the affected zones, which provides granular control to detect and mitigate specific flood types (e.g., SYN, UDP, ICMP) at the zone level. This profile, configured under Network > Zone Protection, includes settings like flood protection thresholds and logging, targeting the attack source’s impact on the affected zones.

Why Other Options Are Incorrect:
A. Apply DoS profile to security rules allow traffic from outside:
A DoS (Denial of Service) profile can protect against floods, but applying it to Security rules allowing outside traffic would enforce it on all permitted traffic, potentially disrupting legitimate flows. It should be applied via a Zone Protection profile for targeted defense. The PCNSE Study Guide advises zone-level DoS configuration.

B. Add the default Vulnerability Protection profile to all security rules that allow traffic from outside:
Vulnerability Protection profiles address exploits (e.g., buffer overflows in applications), not flood attacks causing packet buffer utilization. Adding it broadly to all rules is inefficient and unrelated to the issue. The PAN-OS 11.1 Administrator’s Guide distinguishes it from flood protection.

C. Enable packet buffer protection for the affected zones:
Packet buffer protection is a global setting and cannot be enabled per zone; it is a data plane resource management feature, not a zone-specific defense. The administrator already enabled it globally, so this option is invalid. The PCNSE Study Guide clarifies its scope.

Practical Steps:
Navigate to Network > Zone Protection.
Create a Zone Protection profile.
Under Flood Protection, configure thresholds (e.g., SYN Flood: Activate at 2000 CPS, Max at 5000 CPS).
Enable logging for flood events.
Apply the profile to the affected zones under Network > Zones.
Commit the configuration.
Monitor packet buffer utilization via Dashboard > Resources Widget or CLI show running resource-monitor.
Verify threat logs (Monitor > Threat Logs) show dropped flood traffic.

Additional Considerations:
Identify the attack source IP and consider a Security policy to block it if persistent. Ensure PAN-OS 11.1 supports these settings, which it does by default.

References:
Palo Alto Networks PAN-OS 11.1 Administrator’s Guide: Details Zone Protection for flood mitigation.
Palo Alto Networks PCNSE Study Guide: Explains packet buffer and zone protection.

C. Test Policy Match

Explanation:

Why "Test Policy Match"?
1.Purpose:
The Test Policy Match tool (in Panorama or firewall) allows administrators to simulate traffic against the policy rulebase before deployment.
It checks which rule matches specific traffic (source, destination, application, etc.) and validates if the intended behavior (allow/deny) occurs.
2.Key Benefits:
Identifies rule misconfigurations (e.g., overly permissive rules).
Ensures policies align with security requirements without live traffic.

Why Not Other Options?
A. Preview Changes
Shows configuration diffs (e.g., new rules), but doesn’t test traffic matching.
B. Managed Devices Health
Monitors device status, not policy logic.
D. Policy Optimizer
Recommends rule adjustments based on logs, but doesn’t simulate traffic.

How to Use:
In Panorama, go to: Policies > Security > Test Policy Match.
Enter traffic parameters (e.g., source IP, destination IP, application).
Review which rule matches and the action (allow/deny).

Reference:
Palo Alto Admin Guide:
"Test Policy Match validates rule precedence and traffic handling before commit."

A. Change destination NAT zone to Trust_L3.

Explanation:
This is a classic U-Turn NAT scenario, where internal users access an internal server using its public IP address. For this to work correctly, the NAT rule must reflect that both source and destination traffic are in the same zone — in this case, Trust_L3.

Why A is Correct:
The destination zone in the NAT rule must match the zone of the translated IP (i.e., the internal server).
Since the public IP is translated to 10.0.0.100, which resides in Trust_L3, the destination zone must be Trust_L3.
If you leave it as Untrust_L3, the firewall won’t match the NAT rule correctly, and the traffic will fail.
📚 Reference:
Palo Alto Networks – U-Turn NAT Configuration

❌ Why Other Options Are Wrong:
B. Dynamic IP translation:
Not relevant — this is a destination NAT scenario, not source NAT.
C. Source NAT zone to Untrust_L3:
Incorrect — the source zone is Trust_L3 and should remain so.
D. Add source translation:
Not required for U-Turn NAT unless there's a specific need to mask internal IPs.

B. GlobalRrotect app and GlobalProtect gateway

Explanation:
The UDP-4501 protocol-port is used for communication between specific components of the GlobalProtect infrastructure on a Palo Alto Networks firewall. UDP-4501 is associated with IPsec VPN traffic, particularly when encapsulated with NAT Traversal (NAT-T) using IKEv2, which is commonly employed by GlobalProtect for secure client-to-gateway connections. The GlobalProtect app (installed on end-user devices) communicates with the GlobalProtect gateway to establish and maintain VPN tunnels, including data transmission and keepalives. This port is critical when the app is behind a NAT device, as it enables the gateway to handle encapsulated IPsec packets. The Palo Alto Networks PAN-OS 11.1 Administrator’s Guide specifies that UDP-4501 is the port used for GlobalProtect app-to-gateway communication, especially in NAT environments, making option B correct as of 09:59 AM PKT on Monday, August 25, 2025.

Why Other Options Are Incorrect:
A. GlobalProtect app and GlobalProtect satellite:
This is incorrect because a GlobalProtect satellite is a secondary gateway or proxy in a split-tunnel or large-scale deployment, and UDP-4501 is not the primary port for app-to-satellite communication. The satellite typically relays traffic, and other ports (e.g., TCP-443) are more relevant. The PCNSE Study Guide notes satellites use different mechanisms.

C. GlobalProtect portal and GlobalProtect gateway:
This is incorrect because the GlobalProtect portal (which handles app configuration and authentication) communicates with the gateway using TCP-443 for management and control, not UDP-4501. UDP-4501 is reserved for data tunneling, not portal-gateway interaction. The PAN-OS 11.1 Administrator’s Guide clarifies this distinction.

D. GlobalProtect app and GlobalProtect portal:
This is incorrect because the app communicates with the portal over TCP-443 for initial connection, authentication, and configuration download, not UDP-4501. UDP-4501 is used for the data plane with the gateway. The PCNSE Study Guide confirms the portal uses HTTP/HTTPS.

Practical Steps:
Navigate to Network > GlobalProtect > Gateways.
Configure the gateway with UDP-4501 enabled (default for IPsec with NAT-T).
Verify the app’s connection settings under Network > GlobalProtect > Portals match the gateway. Test connectivity from the app to the gateway using UDP-4501.
Monitor logs under Monitor > System Logs or GlobalProtect Logs for port-related issues.

Additional Considerations:
Ensure firewalls or NAT devices allow UDP-4501 outbound/inbound. Check PAN-OS version (e.g., 11.1) supports this configuration, which it does by default.

References:
Palo Alto Networks PAN-OS 11.1 Administrator’s Guide: Details UDP-4501 usage for app-to-gateway.
Palo Alto Networks PCNSE Study Guide: Explains GlobalProtect port assignments.

B. High Risk

Explanation:
SSL decryption is resource-intensive, so it should be deployed strategically to maximize security ROI. The High Risk category includes sites known for malware, phishing, command-and-control (C2) activity, and other malicious content. Decrypting traffic to these sites first allows the firewall to:
Inspect encrypted threats that would otherwise evade detection.
Block dangerous traffic before it causes harm.
Prioritize limited decryption resources on the highest-risk traffic.
This approach aligns with Palo Alto Networks' best practices for phased decryption rollout, starting with the most critical threats.

Why the other options are incorrect:
A. Online Storage and Backup:
While this category may contain threats, it is not the highest priority. Decrypting storage traffic can raise privacy concerns and may be subject to compliance restrictions. C. Health and Medicine: This category is often sensitive due to privacy regulations (e.g., HIPAA). Decrypting it without careful consideration may violate compliance requirements.
D. Financial Services:
This category is critical for security but often uses certificate pinning or is highly sensitive to user privacy. Decrypting financial traffic can break applications or trigger legal issues if not handled cautiously.

Reference:
Palo Alto Networks Best Practices for SSL Decryption:
Recommends starting decryption with the High Risk category to quickly reduce the attack surface.
PCNSE Exam Blueprint (Domain 3:
Security Policies and Profiles): Understanding decryption strategies and prioritization is key for effective security policy design.

A. The maximum time that the local firewall waits before going to Active state when another cluster member is preventing the cluster from fully synchronizing

Explanation:
The Cluster Synchronization Timeout (min) defines the maximum time a local firewall in a cluster will wait before transitioning to the Active state, if another cluster member is preventing full synchronization. This setting is critical in HA clustering, where multiple firewalls share session state and must reach a stable configuration before processing traffic.
If a cluster member is in an unstable or unknown state (e.g., Initializing, Suspended, Non-functional), it may block the cluster from reaching full synchronization. The local firewall uses the Cluster Synchronization Timeout to determine how long to wait before proceeding to Active state independently, ensuring that traffic is not indefinitely delayed due to a misbehaving peer.
The timeout can be configured between 0 and 30 minutes, with a default of 0. A value of 0 means the firewall will not wait and will immediately become Active. A positive value allows time for the cluster to stabilize before the firewall takes over.

❌ Why Other Options Are Incorrect:
B. The time that a passive or active-secondary firewall will wait before taking over as the active or active-primary firewall This describes failover hold time, not cluster synchronization timeout.
C. The timeframe within which the firewall must receive keepalives from a cluster member to know that the cluster member is functional This refers to the HA4 Keep-alive Threshold, not the synchronization timeout.
D. The maximum interval between hello packets that are sent to verify that the HA functionality on the other firewall is operational This describes HA hello interval, unrelated to cluster synchronization.

🔗 Valid References:
Ace4Sure PCNSE Question Explanation
Palo Alto Networks TechDocs – Configure HA Clustering