SSL Inbound Inspection is a feature on Palo Alto Networks firewalls that allows the firewall to decrypt and inspect SSL/TLS traffic destined for internal servers (e.g., internal web servers, application servers) hosted behind the firewall. By decrypting this incoming traffic, the firewall gains visibility into the application and content within the encrypted session.
This visibility is essential for applying effective security measures, including:
This is distinct from SSL Forward Proxy (Outbound Inspection), where the firewall decrypts traffic initiated by internal clients going to external websites.
SSL Inbound Inspection works by placing the firewall in a Man-in-the-Middle (MITM) position between the external client and the internal server.
Critical Requirement: For the firewall to successfully decrypt the incoming session and impersonate the internal server to the external client, it MUST possess the internal server's actual SSL/TLS certificate AND its corresponding private key .
This allows the firewall's security engines (App-ID, Threat Prevention, etc.) to inspect the clear-text application data flowing between the client and the server.
Before configuring SSL Inbound Inspection, ensure these are available:
Device > Certificate Management > Certificates
Import
.
Objects > Decryption > Decryption Profile
Add
.
Policies > Decryption
Add
.
service-https
or a custom service object for TCP/443.
Policies > Security
) that allows the initial HTTPS connection.
Policies > NAT
).
Commit the configuration to the firewall.
graph LR Client[External Client] -- 1. HTTPS Request to Public IP --> FW(Firewall); subgraph Firewall DecPol{Decryption PolicySimplified SSL Inbound Inspection Flow.
Matches Public IP,
Action: Decrypt,
Type: SSL Inbound,
Cert: Server Cert+Key} -- Applies --> Traffic; FW_Engines(Inspection Engines
App-ID, Threat Prev,
File Block, URL Filt) -- Inspect Decrypted --> Traffic; SecPol{Security Policy
Allows 'ssl' or
Decrypted App-ID,
Applies Profiles} -- Applies --> Traffic; NATPol{DNAT Policy
Translates Public IP
to Private IP} -- Applies --> Traffic_PostNAT; end FW -- 2. Impersonates Server
(Uses Server Cert+Key) --> Client; FW -- 3. Initiates New SSL
(Cleartext Internally) --> IntServer(Internal Server
Private IP); Client <-. Encrypted Session .-> FW; FW <-. Cleartext for Inspection .-> FW_Engines; FW <-. Potentially Re-Encrypted .-> IntServer; linkStyle 0 stroke:#007bff,stroke-width:1px; linkStyle 1 stroke:#dc3545,stroke-width:2px,color:red; linkStyle 2 stroke:#28a745,stroke-width:1px,color:green; linkStyle 3 stroke:#ffc107,stroke-width:1px,color:orange; linkStyle 4 stroke:#17a2b8,stroke-width:1px,color:teal; linkStyle 5 stroke:#007bff,stroke-width:1px; linkStyle 6 stroke:#6c757d,stroke-width:1px,stroke-dasharray: 5 5; linkStyle 7 stroke:#6c757d,stroke-width:1px,stroke-dasharray: 5 5; linkStyle 8 stroke:#6c757d,stroke-width:1px,stroke-dasharray: 5 5;
For the PCNSE exam, regarding SSL Inbound Inspection:
Regarding traffic subject to Destination NAT (DNAT), specifically for features like SSL Inbound Inspection, it's essential to understand which IP address the different policy engines use for matching:
Policy Type | Destination IP Used for Matching |
---|---|
NAT Policy (Destination NAT) | Original Destination IP (Public IP) |
Decryption Policy | Original Destination IP (Public IP) |
Security Policy | Original Destination IP (Public IP) |
Conclusion: Both Decryption Policy and Security Policy match on the Original (Pre-NAT) Destination IP address when evaluating incoming traffic, even when a Destination NAT rule applies.
When considering Destination NAT (DNAT) for inbound traffic (e.g., external clients connecting to an internal server via a public IP), the Destination Zone used for policy matching follows the principle of evaluating the original packet context:
Policy Type | Source Zone Used for Matching | Destination Zone Used for Matching |
---|---|---|
Decryption Policy | Ingress Interface Zone (e.g., `Untrust`) | Ingress Interface Zone (e.g., `Untrust`) |
Security Policy | Ingress Interface Zone (e.g., `Untrust`) | Ingress Interface Zone (e.g., `Untrust`) |
Conclusion: For inbound traffic subject to DNAT, both Decryption and Security Policies match based on the Pre-NAT Destination Zone context, which is typically the zone of the interface where the traffic arrives.
1. What is the primary goal of configuring SSL Inbound Inspection?
2. What is the MOST critical prerequisite for the firewall to perform SSL Inbound Inspection?
3. In which policy type is SSL Inbound Inspection configured and enabled?
4. When configuring the Decryption Policy rule for SSL Inbound Inspection, which certificate is selected in the 'Certificate' field under the rule's Options?
5. What is a major security implication or risk associated with SSL Inbound Inspection?
6. How does SSL Inbound Inspection enable more effective Threat Prevention?
7. A Decryption Policy rule for SSL Inbound Inspection is configured to match destination IP 203.0.113.10. A DNAT rule translates 203.0.113.10 to internal server 10.1.1.50. Which IP address should the associated Security Policy rule typically match as the destination?
8. SSL Inbound Inspection is generally considered incompatible with which web server feature?
9. What happens if a client attempts to connect to a server protected by SSL Inbound Inspection using an SSL/TLS cipher suite that the firewall does NOT support for decryption?
10. Where do you import the internal server's certificate AND private key for use in SSL Inbound Inspection?