The new firewall passed every test in the lab. Two weeks after go-live, the helpdesk queue fills with the same complaints. Microsoft 365 crawls. SaaS apps time out. Video calls freeze mid-sentence. Someone opens the dashboard and finds the CPU pinned at 95%.
The cause is one setting: deep inspection, switched on across the outbound policy.
This failure shows up in firewall projects constantly, and the product is rarely to blame. The problem starts earlier, when someone sizes the box against the wrong number.
Encryption Hides the Good and the Bad Alike
Most web and SaaS traffic now travels over TLS. That protects users' privacy, and it protects attackers just as well. Malware delivery, command-and-control callbacks, and data exfiltration all ride inside the same encrypted sessions as legitimate business traffic.
A firewall that can't see inside TLS makes decisions on IP addresses, ports, and domain names. Not much else.
So security teams turn on deep inspection. Then performance falls off a cliff.
What the Firewall Actually Does During Deep Inspection
Deep inspection turns the firewall into a man-in-the-middle proxy. For every inspected connection, it:
- Terminates the client's TLS session using a certificate the endpoint trusts.
- Opens a second, separate TLS session to the destination server.
- Decrypts the traffic and passes the cleartext to the IPS, antivirus, application control, and DLP engines.
- Re-encrypts the traffic and forwards it.
That adds up to two full TLS handshakes and two rounds of encryption per session, with content scanning in between. The handshake costs the most. Key exchange runs on asymmetric cryptography (ECDHE or RSA), which burns far more CPU than bulk encryption. A single modern web page can open dozens of connections, so a busy office generates new sessions faster than general-purpose processors can handle.
TLS 1.3 raises the bar again. It makes forward secrecy mandatory, which kills the old approach of passively decrypting traffic with a copy of the server's private key. Full proxy inspection is now the only way to see inside TLS 1.3, and full proxy is the most expensive mode a firewall can run.
Why Datasheet Throughput Misleads Buyers
Firewall datasheets lead with their biggest number: raw firewall throughput. Vendors usually measure it with large UDP packets and every security feature switched off. Real traffic looks nothing like that.
Turn on IPS, application control, and malware scanning, and usable throughput drops. Add SSL inspection, and it drops again, often sharply.
Two figures matter far more for a modern deployment:
- SSL inspection throughput: how much decrypted, fully inspected traffic the device can move.
- SSL inspection connections per second (CPS): how many new TLS sessions the device can set up each second.
CPS is the number teams overlook. A firewall can have plenty of bulk throughput headroom and still stall because it can't complete handshakes fast enough during the 8 a.m. login rush.
Our engineers at IT Builders run into the same pattern again and again in firewall refresh projects. An organization buys a device on headline throughput and deploys it with certificate-only inspection. Months later, an audit or an incident forces full deep inspection. Nobody sized the hardware for that workload, and users feel it before the security team does.
Evaluating Your Firewall Sizing?
The right firewall capacity depends on your real traffic profile: peak sessions, encryption ratio, and the inspection features you actually plan to run.
How FortiGate Handles Inspection Differently
Most firewalls run the entire inspection pipeline on general-purpose x86 CPUs. Every handshake, every decryption, and every signature match competes for the same cores.
FortiGate splits the work across purpose-built silicon that Fortinet calls Security Processing Units (SPUs):
- Network Processors (NP) handle packet forwarding and the session fast path in hardware, so established flows don't consume CPU.
- Content Processors (CP) offload cryptographic work, including TLS handshakes and bulk encryption, and accelerate pattern matching for IPS and antivirus.
- The SP5 system-on-a-chip, found in several newer G-series models, combines these functions on a single chip.
The CPU stays free for policy logic and management while dedicated hardware carries the crypto and scanning load. Fortinet also publishes SSL inspection throughput and CPS figures for every FortiGate model, so teams can size against the workload they'll actually run instead of a lab number.
Hardware alone won't fix a bad design, though.
Six Design Decisions That Protect Performance
1. Size on SSL inspection figures, not firewall throughput. Start from measured data: peak concurrent users, peak new sessions per second, and the share of traffic you plan to decrypt. Then add headroom for growth.
2. Match the inspection mode to the policy. FortiOS supports flow-based inspection (faster, lighter) and proxy-based inspection (deeper, heavier). Most outbound user traffic runs well in flow mode. Reserve proxy mode for policies where the extra depth justifies the cost.
3. Use certificate inspection where deep inspection adds little. Certificate inspection reads the server name and certificate without decrypting the payload. It still supports category-based web filtering at a fraction of the processing cost.
4. Build the exemption list deliberately. Some traffic should stay encrypted: banking, healthcare, and personal-privacy categories; applications that use certificate pinning and break under inspection; and trusted, high-volume flows such as OS and security updates. For organizations in Saudi Arabia, the Personal Data Protection Law (PDPL) adds another reason to document what the firewall decrypts and why.
5. Deploy the inspection certificate before enforcement. Push the CA certificate to managed endpoints through Group Policy or MDM before you switch deep inspection on. Skip this step and day one brings a wave of broken-site tickets.
6. Watch the right metrics after go-live. Track CPU, memory, new session rate, and conserve-mode events. These catch capacity problems before users start reporting them.
The Bottom Line
Traffic will stay encrypted, and so will the threats hiding inside it. Inspecting that traffic at scale takes two things: hardware built for the crypto load, and a design that decides deliberately what to decrypt, how deeply, and where.
IT Builders is an authorized Fortinet Engage Partner holding the Secure Networking: Firewall specialization. Our engineers size FortiGate deployments against real traffic profiles, build inspection policies around the applications the business depends on, and plan cutovers that keep users online.
Planning a firewall refresh or switching on deep inspection?
