SonicWall DPI-SSL — Client vs Server TLS Inspection Done Right

① Why decrypt at all — the encrypted blind spot

The single most important idea: the large majority of web traffic is now TLS-encrypted, so a firewall that cannot decrypt it only sees an opaque tunnel. Malware downloads, command-and-control, data theft and policy-evading apps all ride inside HTTPS precisely because they expect no one to look. Without decryption, your firewall's security services are blind.

DPI-SSL solves this by terminating the TLS session at the firewall, handing the cleartext to the RFDPI engine — Reassembly-Free Deep Packet Inspection — which scans it with Gateway Anti-Virus, IPS, anti-spyware, application control and Capture ATP sandboxing, and then re-encrypting it onward. The firewall sits in the middle of the handshake. Modern SonicOS supports TLS 1.3.

DPI-SSL comes in two modes for opposite directions: Client for outbound user traffic and Server for inbound traffic to servers you host. The rest of this lesson is about getting that distinction — and the certificates each mode needs — right.

② Client DPI-SSL — outbound, re-signed with the firewall CA

Client DPI-SSL protects outbound traffic: your internal users connecting out to external HTTPS sites. The firewall acts as a man-in-the-middle. It intercepts each connection, makes its own TLS session to the real site, and then presents the user's browser a copy of the site's certificate that it has re-signed with the firewall's own CA. That lets it decrypt, inspect with RFDPI, and re-encrypt in both directions.

The certificate trap everyone hits

Because the browser now sees a certificate issued by the firewall's CA — not a public CA it already trusts — you must deploy and trust that CA on every client device. In a Windows estate you push it as a trusted root via Active Directory GPO; for laptops and mobiles you use MDM. Skip this and users get a flood of 'your connection is not private' certificate warnings on nearly every site.

③ Server DPI-SSL — inbound, using the server's own certificate

Server DPI-SSL protects the opposite direction: inbound traffic to servers you host — a public web or mail server sitting behind the firewall. Here there is no man-in-the-middle re-signing. You import the hosted server's own certificate and matching private key into the firewall, so it can decrypt the inbound TLS sessions destined for that server and inspect them with RFDPI for attacks.

When to use which

The interview line: direction decides the mode. Client DPI-SSL = your users going out, and it needs the firewall CA trusted on clients. Server DPI-SSL = the world coming in to your hosted services, and it needs the genuine server cert and key — no client CA push at all. They are configured independently and can run side by side on the same appliance.

④ Exclusions, pinning, performance & a safe rollout

You should not — and sometimes cannot — decrypt everything. Maintain an exclusion list so sensitive and incompatible traffic flows untouched: banking, healthcare and government categories (privacy and compliance), software-update services, and especially certificate-pinned applications. A pinned app rejects any certificate that does not match its hard-coded pin, so decrypting it breaks the app — exclude it.

Roll out without a helpdesk storm

DPI-SSL is resource-intensive: terminate, inspect and re-encrypt all cost CPU, so trying to decrypt every flow can saturate the appliance. Size the firewall for DPI-SSL throughput, enable it per zone, and scope it with address and service objects so you decrypt only what you intend. Deploy the CA to clients first, start on a pilot zone, build the exclusion list, then widen — never flip it on for the whole estate at once.