Overview: Decryption Mirror vs. Decryption Broker

Palo Alto Networks firewalls provide robust capabilities to decrypt and inspect encrypted network traffic, such as SSL/TLS and SSH sessions. This decryption is vital for identifying threats hidden within encrypted flows, enforcing security policies accurately, and maintaining regulatory compliance. However, organizations often employ a multi-layered security strategy, utilizing specialized tools for tasks like advanced intrusion detection, data loss prevention (DLP), or forensic analysis. These tools frequently require access to the cleartext (decrypted) traffic to function effectively.

To bridge this gap, Palo Alto Networks offers two distinct features for exporting decrypted traffic:

• Decryption Mirror: This feature creates a copy of the decrypted packet flow and sends it out a dedicated firewall interface. It's primarily intended for passive monitoring and analysis tools that don't need to be inline with the actual traffic. The original traffic continues its path through the firewall for security inspection and eventual re-encryption.
• Decryption Broker (also known as Network Packet Broker in more recent PAN-OS versions ): This feature redirects the decrypted traffic flow inline through a sequence of external security devices, known as a "security chain". These external devices can inspect and potentially modify or block the traffic before sending it back to the firewall for final processing and re-encryption. This allows for active enforcement by third-party tools.

Choosing between Decryption Mirror and Decryption Broker depends heavily on whether the external tools need to passively observe or actively interact with the traffic flow. This report will explore the operational details, configuration requirements, typical use cases, and limitations of each feature.

Decryption Mirror

Decryption Mirror provides a mechanism to passively monitor decrypted traffic by sending a copy of the cleartext data stream to an external tool without interrupting the primary traffic flow through the firewall.

Workflow

sequenceDiagram
    participant Client
    participant FW as Firewall
    participant Server
    participant MirrorTool as Analysis/DLP Tool

    Client->>+FW: 1. Encrypted Request (HTTPS/SSH)
    Note over FW: Matches Decryption Policy
    FW->>+Server: 2. Encrypted Request forwarded
    Server->>-FW: 3. Encrypted Response
    Note over FW: 4. Performs Decryption (SSL Forward Proxy / Inbound Inspection)
    FW -->> MirrorTool: 5. Copies Decrypted Payload via Mirror Port (Cleartext)
    Note over FW: 6. Applies Security Policies (App-ID, Threat, etc.) to Original Decrypted Flow
    alt Traffic Allowed
        FW->>-Client: 7. Re-encrypts & Forwards Allowed Response
    else Traffic Blocked
        FW--x Client: 7. Blocks Response (based on policy)
    end
             

Detailed traffic flow for Decryption Mirror.

1. Encrypted traffic arrives at the firewall and matches a Decryption Policy rule configured for decryption (e.g., SSL Forward Proxy or SSL Inbound Inspection).
2. The firewall performs the necessary decryption steps (e.g., certificate emulation for Forward Proxy, using the server's private key for Inbound Inspection).
3. If the Decryption Profile applied by the policy rule has "Forward decrypted content" (mirroring) enabled, the firewall duplicates the resulting cleartext packet stream.
4. This cleartext copy is encapsulated (often with a simulated TCP handshake ) and sent out the specially configured "Decrypt Mirror" interface.
5. Concurrently , the original (now decrypted) traffic stream continues through the firewall's standard security processing pipeline (App-ID identification, threat scanning, URL filtering, file blocking, etc.).
6. Based on the security policy outcome for the original stream, the firewall either drops the connection or re-encrypts the allowed traffic and forwards it to its original destination (client or server).
7. The external tool connected to the mirror port receives the cleartext copy for its analysis or logging purposes but does not send traffic back into the mirror port.

Configuration

• License: A specific (free) "Decryption Port Mirror" license must be activated on the Palo Alto Networks support portal and installed on the firewall.
• Interface Configuration: Designate a physical Ethernet interface for mirroring. Navigate to Network > Interfaces > Ethernet , select the interface, and set the Interface Type to Decrypt Mirror . This interface does not require an IP address or zone assignment in the same way as data plane interfaces.
• Decryption Profile: Create or modify a Decryption Profile ( Objects > Decryption > Decryption Profile ). Under the "No Decryption" or relevant protocol tabs (e.g., SSL Forward Proxy), find and enable the option to forward/mirror decrypted content (exact wording may vary slightly by PAN-OS version, e.g., "Forward decrypted content" ). Assign the previously configured Decrypt Mirror interface to this profile setting.
• Decryption Policy: Create a Decryption Policy rule ( Policies > Decryption ) that matches the traffic you want to decrypt and mirror. Apply the configured Decryption Profile to this rule.
• Global Setting: Ensure the global decryption setting Allow forwarding of decrypted content is enabled under Device > Setup > Content-ID > Content-ID Settings .

Use Cases

• Passive Intrusion Detection Systems (IDS): Feeding cleartext traffic to an IDS that analyzes copies without being inline.
• Network Forensics & Recording: Capturing decrypted sessions for incident response, compliance auditing, or troubleshooting.
• Out-of-Band Data Loss Prevention (DLP): Allowing a separate DLP system to analyze decrypted content for sensitive data without impacting the live traffic flow.
• Threat Hunting & Analysis Platforms: Providing cleartext feeds to external security analytics tools.

Limitations and Considerations

• Platform Support: Decryption Mirroring is not supported on VM-Series firewalls deployed in public clouds (AWS, Azure, GCP) or VMware NSX environments. Support exists on various hardware platforms, but always verify compatibility for your specific model and PAN-OS version in the official documentation or datasheets.
• Cleartext Exposure: The mirrored traffic is unencrypted. Secure the physical connection to the mirror port and the receiving device appropriately. Consider regulatory compliance implications (e.g., GDPR, HIPAA) of exporting decrypted data.
• Resource Impact: Decryption itself is CPU-intensive on the firewall. Mirroring adds a smaller, but non-zero, overhead. Monitor firewall resource utilization.
• One Mirror Interface: Typically, only one interface can be configured as type Decrypt Mirror per firewall (or per virtual system if using multi-vsys).
• SSH Limitation: Mirroring of decrypted SSH traffic might be limited or not supported depending on the PAN-OS version. (Check current release notes).

Decryption Broker (Network Packet Broker)

Decryption Broker offers a fundamentally different approach by acting as an orchestrator, redirecting traffic flows through external, inline security devices (a "security chain") for processing, which often includes decryption. This allows organizations to leverage specialized third-party tools for active inspection and enforcement.

Workflow

graph TD
    A[Client] --> B(Firewall Ingress);
    subgraph Firewall
        B --> C{Match Security Policy};
        C -- Allowed --> D{Match Decryption Forwarding Rule?};
        D -- Yes --> E[Redirect to Chain via Broker Interface 1];
        D -- No --> F[Normal FW Processing Decrypt Inspect];
        G[Receive from Chain via Broker Interface 2] --> H{Apply Return Security Policy};
        H -- Allowed --> I[Re-encrypt if needed and Forward];
    end
    subgraph "External Security Chain (Inline)"
        J(Device 1 - e.g., Decryptor) --> K(Device 2 - e.g., IPS/DLP);
        K --> L(Chain Egress);
    end
    E --> J;
    L --> G;
    I --> M[Server];



              

High-level conceptual workflow for Decryption Broker.

1. Encrypted or cleartext traffic enters the firewall.
2. Initial Security Policy lookup occurs.
3. If allowed, the traffic is evaluated against Decryption Forwarding rules ( Policies > Decryption Forwarding ).
4. If a matching Decryption Forwarding rule is found, instead of proceeding with standard firewall decryption/inspection, the firewall redirects the traffic.
   • The rule specifies a target Security Chain object.
   • The firewall uses the ingress broker interface defined in the Security Chain object to send the traffic out towards the first device in the chain.
   • Traffic can be sent encrypted (for the chain to decrypt) or already decrypted by the firewall itself, depending on the configuration and use case.
5. The traffic traverses the inline Security Chain, where each third-party device performs its function (e.g., decryption, IPS inspection, DLP enforcement).
6. The processed traffic exits the last device in the chain and is sent back to the firewall via the egress broker interface defined in the Security Chain object.
7. The firewall receives the traffic from the chain (often now in cleartext).
8. The firewall can then perform its own security processing (App-ID, threat prevention, etc.) on this returned, cleartext traffic based on Security Policy rules applied to the zone associated with the egress broker interface.
9. Finally, if the original flow was encrypted and policy dictates, the firewall re-encrypts the traffic before forwarding it to the ultimate destination.

Where Does Decryption Happen with Broker?

A common point of confusion is whether the Palo Alto Networks firewall still performs decryption when using Decryption Broker. The answer depends on the configuration and the goal:

• Scenario 1: Decryption Offload (Most Common)
  • The primary goal is often to reduce the decryption load on the firewall.
  • In this case, the Decryption Forwarding Rule is configured to forward the traffic in its encrypted state to the Security Chain.
  • Specialized external appliances (like dedicated SSL visibility tools) within the chain perform the actual decryption.
  • The cleartext traffic is then processed by other tools in the chain and/or returned cleartext to the firewall for inspection.
• Scenario 2: Firewall Decrypts First
  • Sometimes, the firewall might need to handle the initial decryption, especially for SSL Forward Proxy scenarios where it needs to emulate the server certificate for the client.
  • The tools in the security chain might not perform decryption themselves but require cleartext input for their specific function (e.g., an inline DLP or specialized IPS).
  • In this case, the firewall performs decryption based on a standard Decryption Policy (like Forward Proxy or Inbound Inspection), and the Decryption Forwarding Rule is configured to forward the resulting decrypted traffic to the Security Chain.

Therefore, while Decryption Broker *facilitates* offloading decryption, the firewall itself *can* still be the component performing decryption depending on how the Decryption Forwarding Rule's "Traffic Type" option is set (Forward Encrypted vs. Forward Decrypted).

Configuration Elements

• License: Requires a specific Decryption Broker or Network Packet Broker license (verify requirements for your platform/version).
• Dedicated Interfaces: At least two interfaces are needed per chain – one to send traffic *to* the chain (ingress broker interface) and one to receive traffic *from* the chain (egress broker interface).
  • These can be configured as Virtual Wire pairs (if the chain is a transparent bridge) or potentially Layer 2 / Layer 3 interfaces depending on the chain's architecture and PAN-OS capabilities.
  • These interfaces are typically dedicated solely to broker traffic.
• Security Chain Objects: Defined under Objects > Decryption > Security Chains . You specify:
  • Chain Type: Layer 2 or Layer 3.
  • Ingress Broker Interface(s).
  • Egress Broker Interface(s).
  • Optionally, tags for policy matching.
• Decryption Forwarding Rules: Defined under Policies > Decryption Forwarding . These rules match traffic based on standard criteria (zones, addresses, services, URL categories, etc.) and specify:
  • Action: Forward to a specific Security Chain.
  • Traffic Type: Forward encrypted , decrypted , or both .
  • Direction: Forward forward flow, reverse flow, or both .
• (Potentially) Service Routes: For Layer 3 security chains where devices have routable IP addresses, static service routes are often needed under Network > Virtual Routers > (select router) > Static Routes > Service Route Configuration to ensure the firewall routes traffic destined for the chain devices out the correct ingress broker interface.
• Security Policies: Need policies allowing the initial traffic to match the forwarding rule, and policies governing the traffic returning from the chain.
• Decryption Policies: Still required if the firewall needs to perform initial decryption (e.g., for Forward Proxy certificate emulation before sending cleartext to the chain) or re-encryption upon return.
• Health Monitoring: Configure health checks ( Objects > Decryption > Security Chain Health Check ) to monitor devices in the chain and define fail actions (e.g., bypass chain).

Use Cases

• SSL/TLS Decryption Offload: Sending encrypted traffic to specialized, high-performance decryption appliances, reducing CPU load on the firewall.
• Inline Third-Party Security Tools: Integrating devices like dedicated Web Application Firewalls (WAFs), advanced Intrusion Prevention Systems (IPS), inline Data Loss Prevention (DLP) tools, or Content Disarm & Reconstruction (CDR) platforms that require inline access to cleartext traffic for active enforcement.
• Complex Service Chaining: Routing traffic sequentially through multiple different security inspection tools based on policy.
• Centralized Inspection Hubs: Using the firewall to orchestrate traffic flows to a pool of centralized inspection tools.
• Load Balancing (within chain): While the firewall directs to the chain, the chain itself might contain load balancers to distribute load across multiple identical tools.

Limitations and Considerations

• Increased Latency: Redirecting traffic out of the firewall, through external devices, and back adds network hops and processing time, increasing overall latency.
• Complexity: Configuration involves multiple components (interfaces, rules, objects, routes) and coordination with third-party devices. Troubleshooting can be more involved.
• Single Point of Failure (Chain): If a device in the security chain fails and health monitoring/bypass is not configured correctly, it can become a bottleneck or break the traffic flow.
• Symmetric Return Path: Ensuring traffic returns correctly from the chain, especially in asymmetric routing environments, requires careful planning and potentially source NAT or policy-based forwarding on the firewall.
• Platform/Version Dependencies: Specific features, interface type support (L2/L3 chains), and limitations can vary significantly between PAN-OS versions and firewall platforms. Always consult the documentation for your specific setup.

Comparison Summary: Decryption Mirror vs. Broker

Performance Considerations

Decryption Mirror

• The main performance impact comes from the firewall performing the decryption itself, which consumes CPU resources. The load depends on the volume of decrypted traffic, cipher suites used, and firewall model capacity.
• The act of mirroring the decrypted traffic adds a secondary, generally smaller overhead compared to the decryption process.
• Throughput on the Decrypt Mirror interface itself is limited by the physical port speed (e.g., 1Gbps, 10Gbps). Ensure the receiving tool can handle the volume of mirrored traffic.

Decryption Broker

• If used for decryption offload , it can significantly reduce the decryption CPU load on the Palo Alto Networks firewall, potentially improving overall firewall throughput for other tasks.
• However, redirecting traffic through the external security chain inherently adds network latency for each hop in the chain. The total latency depends on the number of devices and their individual processing times.
• The performance bottleneck might shift from the firewall's decryption capacity to the throughput capacity of the devices within the security chain or the broker interfaces themselves.
• Complex forwarding rules and policy lookups for traffic returning from the chain still consume firewall resources.

Choosing between Mirror and Broker requires balancing the need for inline external processing (Broker) against the desire for passive visibility (Mirror) and considering the performance trade-offs (FW CPU load vs. network latency).

Knowledge Check: Decryption Mirror vs. Broker

Test your understanding of the concepts.