1. URL Filtering & Category Blocking (Without Security Profiles)
Scenario:Your organization wants to block access to gambling websites, but you are not allowed to use Security Profiles or Custom URL Categories.
✅ Question: How can you achieve this requirement using only security policy rules?
Expected Answer:
· Create a new security policy rule.
· Set the Source Zone (e.g., Inside), and Destination Zone (e.g., Outside).
· Set Application to "any" and Service/Port to "any."
· Under the URL Category section, select "gambling" from the predefined categories.
· Set the Action to "Deny."
· Place the rule above any general allow rules.
2. Troubleooting 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 troubleoot this issue?
Expected Answer:
1. Check Security Policy: Verify if there is a blocking rule for this website.
2. URL Filtering Logs: Check Monitor > URL Filtering to see if it's categorized as blocked.
3. Traffic Logs: Go to Monitor > Traffic and filter logs for 192.168.1.20 to see if traffic is denied.
4. DNS Resolution: Ensure example.com resolves correctly using nslookup or dig.
5. Check SSL Decryption: If the site uses HTTPS and SSL decryption is not enabled, it may be categorized incorrectly.
6. Test with IP Address: Try accessing the site via IP to check if it’s a DNS issue.
3. 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:
o Original Packet: Source Zone = Untrust, Destination Zone = Untrust, Destination Address = 203.0.113.20, Service = HTTPS
o Translated Packet: Destination Address = 10.1.1.10
2. Create a Security Policy Rule:
o Source Zone: Untrust
o Destination Zone: DMZ
o Destination Address: 10.1.1.10
o Application: Web-browsing, SSL
o Service: HTTPS
o Action: Allow
4. 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:
o Source User: Add finance department AD group.
o Destination Address: finance.company.com.
o Application: Specify the financial app (if known) or allow web-browsing/SSL.
o Action: Allow.
· Deny All Other Users: Add a deny rule for non-finance users below the allow rule.
5. SSL Decryption Troubleooting
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 ould be excluded.
· Verify Logs in Monitor > Decryption: Look for errors indicating SSL handake failures.
· Modify Decryption Policy:
o Add the problematic sites under the "No Decryption" rule.
o Use the "SSL Forward Proxy" method only where required.
6. App-ID vs Port-Based Rules
Scenario:A network administrator configured a rule to allow s on port 22, but users report they can still use S 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 S traffic on other ports (e.g., 443).
· Fix:
o Change the rule to use App-ID (S) instead of a specific port.
o Ensure an implicit deny rule follows it to block unexpected S traffic on other ports.
7. 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-aring applications.
· Create a security policy rule that:
o Allows Google Drive/Dropbox browsing.
o Blocks "file-upload" under Application Settings.
o Enables File Blocking Profile to block specific file types (e.g., .zip, .csv).
8. Failover & High Availability (HA)
Scenario:Your organization has two Palo Alto firewalls in Active/Passive HA mode. Users report an outage even though failover ould be automatic.
✅ Question: What could be the reasons for the failure?
Expected Answer:
· Check HA Status: Go to Daboard > 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.
1. Scenario: 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:
o External client (198.51.100.50) sends an HTTPS request to 203.0.113.20 (Public IP).
2. Firewall Receives Traffic:
o The firewall receives the request on its Untrust (outside) interface.
3. NAT Rule Processing (Destination NAT):
o The firewall translates 203.0.113.20 (public IP) to 10.1.1.10 (private server IP in DMZ).
4. Security Policy Check:
o 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:
o The firewall forwards the packet to 10.1.1.10.
o The web server processes the request and sends a response.
6. Reverse Flow (Source NAT on Response):
o The server's response follows the same security policy.
o 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:
o The external client (198.51.100.50) receives the HTTPS response and establies the session.
2. Scenario: 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:
o The internal user (192.168.1.20) sends an HTTPS request to example.com (93.184.216.34).
2. Firewall Receives Traffic:
o The firewall receives the request on its Trust (inside) interface.
3. Security Policy Check:
o 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):
o The firewall translates 192.168.1.20 (private IP) to 203.0.113.100 (public IP assigned by ISP).
5. Packet Sent to Internet:
o The firewall forwards the request to example.com (93.184.216.34).
6. Server Responds:
o The web server at example.com sends an HTTPS response back to 203.0.113.100.
7. Reverse NAT (DNAT):
o The firewall receives the response.
o It translates 203.0.113.100 back to 192.168.1.20 (original private IP).
8. Client Receives Response:
o The internal user (192.168.1.20) successfully loads example.com.
Summary of Traffic Flow Differences
Traffic Type | Outside to DMZ | Inside to Outside |
Source IP (Before NAT) | Public (Client IP) | Private (192.168.1.20) |
Destination IP (Before NAT) | Public IP of Server (203.0.113.20) | Public Website (example.com) |
NAT Type Used | DNAT (Public IP → Private IP) | SNAT (Private IP → Public IP) |
Security Rule Zones | Untrust → DMZ | Trust → Untrust |
Reverse Traffic Processing | SNAT (Private IP → Public IP) | DNAT (Public IP → Private IP) |
Scenario-Based Question on "Incomplete" Application in Palo Alto Traffic Logs
Scenario 1: Incomplete Traffic Due to Handake 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 troubleoot it?
�� Expected Answer:
1. TCP Handake Not Completed:
o The client sent a SYN, but the server did not respond (server down, firewall blocking, or routing issue).
o Check for TCP SYN without SYN-ACK in traffic logs or use packet capture.
2. Dropped by Security Policy:
o A Palo Alto security rule may be blocking the SYN-ACK or the return traffic.
o Check Monitor > Traffic Logs for a "deny" action.
3. Session Timeout Before Application Identification:
o If the session is closed before enough packets are seen, Palo Alto marks it as incomplete.
o Use CLI:
Show session all filter source 192.168.1.10
to check if the session is timing out quickly.
4. Asymmetric Routing Issue:
o If the outbound and inbound traffic takes different paths, the firewall may not see the full session.
o 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.
Scenario 2: 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):
o Palo Alto's Threat Prevention module could be blocking suspicious packets.
o Check the Threat Logs (Monitor > Threat Logs) to see if an attack was detected.
2. SSL Decryption Issue:
o If SSL decryption is enabled but not properly configured, the firewall may drop traffic that cannot be decrypted.
o Check Monitor > Traffic Logs for decryption errors.
3. Zone Protection or DoS Policy Blocking Traffic:
o Palo Alto’s Zone Protection Profile may be dropping TCP SYN packets or low TTL packets.
o Check in Network > Network Profiles > Zone Protection and disable temporarily for testing.
✅ Troubleooting Steps:
· Disable Security Profiles Temporarily:
o Modify the security policy and remove Anti-Spyware, IPS, or Antivirus to check if traffic flows.
· Check SSL Decryption Logs:
o 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
Scenario 3: 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 ows "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:
o If source NAT (SNAT) is incorrectly applied, the external server may not be able to respond properly.
o Verify Policies > NAT Rules to ensure correct source NAT.
2. Server Replies to Wrong IP (NAT Pool Issue):
o 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:
o If NAT is applied but security rules are not adjusted accordingly, the return traffic may be blocked.
o Check if the translated IP matches the security rule’s source IP.
✅ Troubleooting Steps:
· Check NAT rules to ensure correct SNAT is applied:
ow running nat-policy
· Use Packet Capture to verify the translated IP.
· Check logs for dropped return traffic from the web server.
Summary of Troubleooting "Incomplete" Application Logs
Issue | Possible Cause | Troubleooting |
TCP Handake Not Completed | Firewall blocking SYN/ACK | Check logs, packet capture |
Security Policy Dropped | Policy misconfigured | Check Monitor > Traffic Logs |
SSL Decryption Failure | Certificate issue | Check Monitor > Decryption Logs |
Asymmetric Routing | Return path different | Verify routing, session browser |
NAT Issue | Wrong IP translation | Check Policies > NAT Rules |
Zone Protection | SYN flood protection enabled | Check Zone Protection Profile |
1. 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:
o The client closed the connection before completing the handshake.
o The destination is not responding.
o The security policy is blocking traffic before the application is fully identified.
o An issue with asymmetric routing or a firewall in the path dropping packets.
2. How can I initiate a failover using the CLI on a Palo Alto firewall?
· Use the command:
request high-availability state suspend
· This forces the firewall into a suspended state, causing a failover.
· To verify HA status:
show high-availability state
· To manually revert to active:
request high-availability state functional
3. What are the different types of packet captures available through both the GUI and CLI on Palo Alto firewalls?
· GUI:
o Navigate to Monitor > Packet Capture.
o Capture stages:
§ receive – Captures packets as they enter the firewall.
§ firewall – Captures packets being processed by the firewall.
§ drop – Captures dropped packets.
§ transmit – Captures packets leaving the firewall.
· CLI:
o Start capture:
tcpdump filter "host <IP_address>"
o View captured packets:
view-pcap follow yes
4. 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:
o Ensure HA1 and HA2 links are properly configured.
o Use backup HA links (HA1 backup).
o Enable "Heartbeat Backup" and "Monitor Hold Time" settings.
5. Can you explain the roles of HA1 and HA2 links in Palo Alto Networks' HA setups?
· HA1 (Control Link):
o Used for state synchronization, heartbeat monitoring, and failover messages.
o Typically uses Management Interface or a dedicated HA port.
· HA2 (Data Link):
o Syncs session tables, forwarding tables, and NAT tables.
o Uses a high-speed interface like Ethernet 1/1 to prevent packet loss.
· HA3 (for Active-Active mode):
o Used for forwarding packets in asymmetric routing scenarios.
6. What is the procedure to upgrade a Palo Alto firewall?Upgrading a Palo Alto Networks Firewall involves several steps to ensure a smooth transition without disrupting network security. Below is a structured procedure:
· Pre-Upgrade Preparation
· Review Release Notes
· Check the release notes for the new PAN-OS version on Palo Alto’s website.
· Identify any known issues, new features, and deprecated functionalities.
Check Compatibility
· Verify that the firewall model supports the target PAN-OS version.
· Ensure Panorama (if used) is upgraded before managed firewalls.
Backup Configuration & Logs
· Export Configuration: Go to Device > Setup > Operations > Export Named Configuration Snapshot.
· Export Logs (Optional): If needed for audit purposes.
· Take a snapshot or backup VM (if applicable).
Verify Licensing & Support
· Ensure the firewall has an active Support License to download updates.
· Go to Device > Licenses and validate.
Check HA Status (If Applicable)
· Ensure HA synchronization is successful.
· Failover to passive (if needed) for minimal downtime.
Plan Maintenance Window
· Inform stakeholders about potential downtime (usually 5–10 minutes for standalone firewalls).
Upgrade Procedure
Download & Install the Base Image
· If upgrading across major versions (e.g., 9.1 → 10.1), first install the immediate base version (e.g., 10.0.0) before moving to the preferred version.
· Go to Device > Software, download, and install.
Upgrade to the Target Version
· Download the required PAN-OS version.
· Install the image (device will reboot).
Verify Post-Upgrade Functionality
· Log in and check System Logs (Monitor > Logs > System).
· Verify interfaces, security policies, and traffic logs.
· Ensure VPN, HA, and routing protocols (BGP, OSPF) are functioning.
Post-Upgrade Tasks
· Re-enable HA (If Disabled)
· Re-enable HA and failover to test redundancy.
· Reinstall Dynamic Updates
Go to Device > Dynamic Updates and update:
· Antivirus
· Applications and Threats
· Wildfire
· URL Filtering
· Monitor for Anomalies
· Check for traffic flow and latency issues.
· Validate logs for any upgrade-related errors.
· Commit & Save Configuration
· Run Commit and take a fresh backup.
Best Practices
· Always upgrade one firewall at a time in an HA setup.
· Avoid skipping base versions when upgrading major releases.
· Keep out-of-band access (console or management interface) ready in case of issues.
· Test critical applications and VPNs after the upgrade.
· If issues arise, consider downgrading (Device > Software > Revert).
7. In IPsec VPN configurations:
· If Phase 1 is down, what could be the potential issues?
o Mismatched ISAKMP (IKE) settings (encryption, authentication, DH group, lifetime).
o Incorrect peer IP or pre-shared key.
o Firewall rules blocking ISAKMP traffic (UDP 500/4500).
· If Phase 2 is down, how should one troubleshoot it?
o Mismatched encryption, authentication settings in IPsec settings.
o PFS (Perfect Forward Secrecy) settings mismatch.
o Incorrect Proxy IDs or subnet mismatch.
· If both phases are up but traffic is still not passing, what could be the problem?
o Security policy not allowing VPN traffic.
o NAT issue interfering with IPsec.
o Routing issues (incorrect static or dynamic routes).
8. What are App-ID and application override features in Palo Alto Networks?
· App-ID:
o Identifies applications using a combination of traffic patterns, signatures, heuristics, and decryption.
o Used to enforce policies based on applications rather than ports.
· Application Override:
o Forces the firewall to classify specific traffic as a particular application, bypassing App-ID checks.
o Useful when custom applications are misidentified.
9. What are device groups and templates in Panorama, and how do they function?
· Device Groups:
o Used to organize firewalls into logical groups.
o Policies and objects are pushed to specific firewalls in a group.
· Templates:
o Used to configure network and device settings like interfaces, DNS, NTP, HA.
o Helps maintain uniform configurations across multiple firewalls.
10. How can I add a firewall to Panorama for centralized management?
· On the firewall:
o Go to Device > Setup > Management > Panorama Settings.
o Enter the Panorama IP and Commit.
· On Panorama:
o Go to Panorama > Managed Devices > Add.
o Enter the firewall serial number and Commit.
· Push a template and device group to complete the configuration.
11. What are the different types of NAT configurations in Palo Alto Networks, including U-turn NAT?
· Source NAT: Changes the source IP of packets leaving the firewall.
· Destination NAT: Changes the destination IP of incoming packets.
· Static NAT: Provides a fixed one-to-one mapping.
· Dynamic IP and Port NAT (DIPP): Uses a pool of IPs with port translation.
· U-turn NAT: Allows internal users to access internal servers using the public IP.
12. 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:
o Device > Setup > Services > Service Route Configuration.
o Select custom and specify the source interface and IP.
13. Packet Flow in Palo Alto Networks
· Ingress Stage: Packet enters an interface.
· Security Policy Lookup: Determines if the packet is allowed or denied.
· Session Setup: Creates a session if allowed.
· Application and Content Inspection: Applies App-ID, threat detection, and security profiles.
· NAT and Forwarding: Applies NAT and forwards based on routing.
· Egress Stage: Packet leaves the firewall.