Paloalto Scenario based questions and answers

Preparing for a Palo Alto interview requires more than understanding concepts—it requires practical problem-solving. In this blog, we share essential Palo Alto scenario-based interview questions and answers to help you confidently handle real-world firewall scenarios.

🧱 Troubleshooting Website Access Issue

Scenario: A user (192.168.1.20) reports they cannot access example.com, but they can access other websites.

❓ Question: What steps will you take to troubleshoot this issue?

✅Expected Answer:

• Check Security Policy: Verify if there is a blocking rule for this website.
• URL Filtering Logs: Check Monitor > URL Filtering to see if it’s categorized as blocked.
• Traffic Logs: Go to Monitor > Traffic and filter logs for 192.168.1.20 to see if traffic is denied.
• DNS Resolution: Ensure example.com resolves correctly using nslookup or dig.
• Check SSL Decryption: If the site uses HTTPS and SSL decryption is not enabled, it may be categorized incorrectly.
• Test with IP Address: Try accessing the site via IP to check if it’s a DNS issue.

🧱 NAT Rule Configuration

 Scenario: Your company has a web server (10.1.1.10) in the DMZ zone, and you need to allow external users to access it via 203.0.113.20 on port 443.

❓Question: How will you configure NAT and security policies for this requirement?

✅Expected Answer:

1. Create a NAT Rule: 

• Original Packet: Source Zone = Untrust, Destination Zone = Untrust, Destination Address = 203.0.113.20, Service = HTTPS
• Translated Packet: Destination Address = 10.1.1.10

2. Create a Security Policy Rule: 

• Source Zone: Untrust
• Destination Zone: DMZ
• Destination Address: 10.1.1.10
• Application: Web-browsing, SSL
• Service: HTTPS
• Action: Allow

🧱 User-ID Based Access Control

Scenario: Your company wants only finance department users to access the financial application (finance.company.com), while blocking all other users.

❓ Question: How will you configure the firewall to meet this requirement?

✅Expected Answer:

· Enable User-ID: Ensure User-ID is configured and integrated with Active Directory.

· Create a Security Policy Rule: 

• Source User: Add finance department AD group.
• Destination Address: finance.company.com.
• Application: Specify the financial app (if known) or allow web-browsing/SSL.
• Action: Allow.

Deny All Other Users: Add a deny rule for non-finance users below the allow rule.

🧱 SSL Decryption Troubleshooting

Scenario: Users complain that certain banking and healthcare websites are inaccessible after enabling SSL decryption.

❓ Question: What could be the reason and how would you fix it?

✅Expected Answer:

• Check Decryption Exceptions: Some websites (banking, healthcare) use SSL pinning and would be excluded.
• Verify Logs in Monitor > Decryption: Look for errors indicating SSL handshake failures.
• Modify Decryption Policy:
  • Add the problematic sites under the “No Decryption” rule.
  • Use the “SSL Forward Proxy” method only where required.

🧱 App-ID vs Port-Based Rules

Scenario: A network administrator configured a rule to allow service on port 22, but users report they can still use service over port 443.

 ❓Question: Why is this happening, and how do you fix it?

✅Expected Answer:

Issue: The rule is port-based (TCP/22), but App-ID can detect service traffic on other ports (e.g., 443).

Fix: 

• Change the rule to use App-ID (S) instead of a specific port.
• Ensure an implicit deny rule follows it to block unexpected S traffic on other ports.

🧱 Data Exfiltration Prevention

Scenario: The security team suspects that employees are uploading sensitive files to cloud storage sites (e.g., Google Drive, Dropbox).

 ❓Question: How can you prevent file uploads without blocking the entire website?

✅Expected Answer:

• Use App-ID to allow web browsing but block file-sharing applications.
• Create a security policy rule that:
  • Allows Google Drive/Dropbox browsing.
  • Blocks “file-upload” under Application Settings.
  • Enables File Blocking Profile to block specific file types (e.g., .zip, .csv).

🧱 Failover & High Availability (HA)

Scenario: Your organization has two Palo Alto firewalls in Active/Passive HA mode. Users report an outage even though failover would be automatic.

❓Question: What could be the reasons for the failure?

✅Expected Answer:

• Check HA Status: Go to Dashboard > High Availability and verify the state of both firewalls.
• Check HA Link Connectivity: Ensure HA1 (control link) and HA2 (data link) are both up.
• Monitor Logs: Look for failover events in System Logs.
• Ensure Preemption is Enabled: If preemption is disabled, the passive firewall won’t take over.
• Check HA Path Monitoring: If critical interfaces are down, failover might not trigger correctly.

🧱 Traffic from Outside (Internet) to DMZ (Public Server)

Scenario:

Your organization hosts a web server (10.1.1.10) in the DMZ zone, and external users access it via 203.0.113.20 on port 443.

❓Question: Explain the traffic flow when an external client (198.51.100.50) accesses https://203.0.113.20.

✅Traffic Flow Steps:

1. Client Initiates Connection:

• External client (198.51.100.50) sends an HTTPS request to 203.0.113.20 (Public IP).

2. Firewall Receives Traffic:

• The firewall receives the request on its Untrust (outside) interface.

3. NAT Rule Processing (Destination NAT):

• The firewall translates 203.0.113.20 (public IP) to 10.1.1.10 (private server IP in DMZ).

4. Security Policy Check:

The firewall checks security rules:

• Source Zone: Untrust
• Destination Zone: DMZ
• Destination IP: 10.1.1.10
• Application: web-browsing, SSL
• Service: TCP/443
• Action: Allow

5. Traffic Sent to DMZ Server:

• The firewall forwards the packet to 10.1.1.10.
• The web server processes the request and sends a response.

6. Reverse Flow (Source NAT on Response):

• The server’s response follows the same security policy.
• Source NAT (SNAT): The firewall replaces 10.1.1.10 with 203.0.113.20 so the client sees the expected public IP.

7. Client Receives Response:

• The external client (198.51.100.50) receives the HTTPS response and establies the session.

🧱 Traffic from Inside (LAN) to Outside (Internet)

Scenario:

An internal user (192.168.1.20) wants to browse the internet (https://example.com). The Palo Alto firewall does Source NAT to allow the private IP to access the internet.

❓ Question: Explain the traffic flow when 192.168.1.20 browses https://example.com.

✅Traffic Flow Steps:

1. Client Initiates Connection:

• The internal user (192.168.1.20) sends an HTTPS request to example.com (93.184.216.34).

2. Firewall Receives Traffic:

• The firewall receives the request on its Trust (inside) interface.

3. Security Policy Check:

The firewall checks security rules:

• Source Zone: Trust
• Destination Zone: Untrust
• Destination IP: example.com (93.184.216.34)
• Application: web-browsing, SSL
• Service: TCP/443
• Action: Allow

4. NAT Rule Processing (Source NAT – SNAT):

• The firewall translates 192.168.1.20 (private IP) to 203.0.113.100 (public IP assigned by ISP).

5. Packet Sent to Internet:

• The firewall forwards the request to example.com (93.184.216.34).

6. Server Responds:

• The web server at example.com sends an HTTPS response back to 203.0.113.100.

7. Reverse NAT (DNAT):

• The firewall receives the response.
• It translates 203.0.113.100 back to 192.168.1.20 (original private IP).

8. Client Receives Response:

• The internal user (192.168.1.20) successfully loads example.com.

🧱 Incomplete Traffic Due to Handshake Failure

Scenario:A network administrator notices that HTTPS traffic from an internal client (192.168.1.10) to an external website (example.com) is owing “incomplete” under the Application column in Palo Alto traffic logs.

 ❓Question: What could be the possible reasons for this issue, and how can the administrator troubleshoot it?

 ✅Expected Answer:

1. TCP Handake Not Completed:

• The client sent a SYN, but the server did not respond (server down, firewall blocking, or routing issue).
• Check for TCP SYN without SYN-ACK in traffic logs or use packet capture.

2. Dropped by Security Policy:

• A Palo Alto security rule may be blocking the SYN-ACK or the return traffic.
• Check Monitor > Traffic Logs for a “deny” action.

3. Session Timeout Before Application Identification:

• If the session is closed before enough packets are seen, Palo Alto marks it as incomplete.
• Use CLI:
  • Show session all filter source 192.168.1.10 [to check if the session is timing out quickly.]

 4. Asymmetric Routing Issue:

• If the outbound and inbound traffic takes different paths, the firewall may not see the full session.
• Check the routing table and logs.

✅ Troubleooting Steps:

• Packet Capture to check SYN-ACK responses.
• Session Browser CLI:
  • show session all filter source 192.168.1.10

• Modify Security Policy to allow bidirectional traffic.
• Check NAT Configuration for incorrect translations.

🧱 Incomplete Traffic Due to Security Profile Blocking

Scenario: A company has a security rule allowing HTTP and HTTPS traffic from internal users to the internet. However, users report that some HTTPS websites are not opening, and the logs ow “incomplete” under the Application column.

❓Question: Which security features in Palo Alto might be blocking the traffic, and how can this be verified?

✅Expected Answer:

1. Threat Prevention Features (IPS, Antivirus, Anti-Spyware):

• Palo Alto’s Threat Prevention module could be blocking suspicious packets.
• Check the Threat Logs (Monitor > Threat Logs) to see if an attack was detected.

2. SSL Decryption Issue:

• If SSL decryption is enabled but not properly configured, the firewall may drop traffic that cannot be decrypted.
• Check Monitor > Traffic Logs for decryption errors.

3. Zone Protection or DoS Policy Blocking Traffic:

• Palo Alto’s Zone Protection Profile may be dropping TCP SYN packets or low TTL packets.
• Check in Network > Network Profiles > Zone Protection and disable temporarily for testing.

✅ Troubleooting Steps:

• Disable Security Profiles Temporarily: 
  • Modify the security policy and remove Anti-Spyware, IPS, or Antivirus to check if traffic flows.
• Check SSL Decryption Logs: 
  • If SSL Decryption is enabled, verify under Monitor > Decryption Logs.
• Run CLI Debug for Dropped Packets: 
  • show counter global filter packet-filter yes delta yes

🧱 Incomplete Traffic Due to NAT Misconfiguration

Scenario: A client (192.168.1.20) in the trust zone is trying to reach an external web server (203.0.113.10), but the application column shows “incomplete” in traffic logs. The security rule allows HTTPS traffic, and NAT is configured for outbound internet access.

❓Question: How can NAT cause incomplete sessions, and what steps can be taken to troubleoot?

✅Expected Answer:

1. Incorrect NAT Translation:

• If source NAT (SNAT) is incorrectly applied, the external server may not be able to respond properly.
• Verify Policies > NAT Rules to ensure correct source NAT.

2. Server Replies to Wrong IP (NAT Pool Issue):

• If the firewall is using a NAT pool but does not have enough available public IPs, some connections may not get the correct translation.

3. NAT Mismatch in Security Policies:

• If NAT is applied but security rules are not adjusted accordingly, the return traffic may be blocked.
• Check if the translated IP matches the security rule’s source IP.

✅ Troubleooting Steps:

• Check NAT rules to ensure correct SNAT is applied:
  • show running nat-policy
•  Use Packet Capture to verify the translated IP.
• Check logs for dropped return traffic from the web server.

🧱 Why am I observing ‘incomplete’ applications in the monitoring section of Palo Alto Networks?

An “incomplete” application means that a TCP handshake did not complete, or there was no data after the handshake.

Causes:

• The client closed the connection before completing the handshake.
• The destination is not responding.
• The security policy is blocking traffic before the application is fully identified.
• An issue with asymmetric routing or a firewall in the path dropping packets.

🧱 How can I initiate a failover using the CLI on a Palo Alto firewall?

Use the command on active firewall: #request high-availability state suspend

This forces the active firewall move into a suspended state, causing a failover.

To verify HA status: #show high-availability state

To manually revert to firewall to functional: #request high-availability state functional

To fail back you have to run suspend command again in current active. (incase of preemption disabled, if preemption is enabled once firewall is made functional it will auto negotiate and lower priority will become active.)

🧱 What is a split-brain scenario in the context of Palo Alto Networks’ High Availability (HA) configurations?

✅Split-brain occurs when both firewalls in an HA pair become active due to a communication failure between them. This can cause duplicate traffic flows, routing issues, and network instability.

✅Prevention Measures: 

• Ensure HA1 and HA2 links are properly configured.
• Use backup HA links (HA1 backup).
• Enable “Heartbeat Backup” and “Monitor Hold Time” settings.

🧱 What is a service route in Palo Alto Networks, and how is it configured?

✅A service route determines which interface is used for firewall services (e.g., updates, authentication, logging).

Configuration:

Device > Setup > Services > Service Route Configuration. Select custom and specify the source interface and IP.

🧱 What is the file extension of palo alto firewall backup?

✅ .xml = configuration snapshot

✅ .tgz = device state

✅.tar.gz = Tech Support file (TSF)

🧱 What does configuration snapshot contains?

✅ Configuration Snapshot (.xml) contains running configuration including Security & NAT Policies, Objects, Network setting, Profiles, device setting, certificate (may not include private key). If you want a full restoration or RMA then device state file is recommended.

🧱What does Device state file contains?

✅ Export the firewall state information as a bundle. Besides the running configuration, the state information includes device group and template settings pushed from Panorama. If the firewall is a GlobalProtect portal, the information also includes certificate information, a list of satellites, and satellite authentication information. If you replace a firewall or portal, you can restore the exported information on the replacement by importing the state bundle.

🧱 IPsec Tunnel is UP but traffic is not passing

Scenario: You configured a site-to-site IPsec tunnel between HQ and Branch.
Tunnel status shows UP on both firewalls, but users cannot access servers on the other side. How do you troubleshoot?

✅Expected answer:

Check Phase 2 selectors (proxy IDs)

• Ensure both sides have correct local/remote subnets.
• Mismatch = tunnel up but no traffic.

Verify security policies

• Allow rule from VPN zone → LAN zone.
• Many people forget the return rule.

Check routing

• Static route or dynamic routing pointing to tunnel interface.
• No route = no traffic even if tunnel is up.

Check NAT exemption

• Make sure VPN traffic is not NATed.

Check traffic logs

• Monitor → Traffic
• Filter by source subnet.

Check counters

• See if packets are encrypted/decrypted.

“Tunnel up only means Phase 1 is okay. Real test is Phase 2 selectors + routing + policies.”

🧱 IPsec Tunnel flaps (disconnects every few minutes)

Scenario: A site-to-site IPsec tunnel comes up but drops every 5–10 minutes. What could be the cause and how do you fix it?

✅Most common real causes:

1. DPD / Keepalive mismatch

• One side has Dead Peer Detection enabled, other doesn’t.
• Causes tunnel teardown.

2. Lifetime mismatch

• Phase 1 or Phase 2 timers different.
• Re-key fails → tunnel drops.

3. NAT device in between

• ISP router doing NAT.
• Fix: enable NAT-T (UDP 4500).

4. Asymmetric routing

Return traffic uses different path.

Firewall drops session.

5. MTU / Fragmentation issue

• Large packets drop.
• Fix: reduce MTU / enable MSS clamping.

✅How you troubleshoot in real life:

Check VPN logs:

• Look for re-key failures.

Compare:

• Encryption algorithms
• Hash
• DH groups
• Lifetimes

Run: #show vpn ipsec-sa

Capture traffic:

• See if ESP packets stop.

Flapping tunnels are almost always DPD, lifetime, or NAT-related — not policies.

🧱How do you upgrade HA pair?

✅ First do pre requisite check:

Make sure Preemption is disabled, Config sync is disabled,

Backup is taken,

Review release note for any behavior change,

Perform failover test first,

Upgrade passive and then failover,

Validate traffic and once verified proceed with next devce,

Validate config sync,

Take after upgrade backup.

Reference https://ictkb.com/upgrade-paloalto-firewall-in-ha-mode/