Why this matters — the airport-security analogy
Imagine the security stack at Mumbai T2. Every passenger walks the same line, but each layer of the check is doing something different. Boarding-pass scan asks "where are you going?" — that's your Web Filter. X-ray asks "what's in the bag?" — that's App Control. Behavior analyst watches gait and nervousness — that's IPS. Bomb-sniffing dog is the chemical signature check — that's AV. And when CISF wants to open the bag because something looks weird? That's deep-inspection — the firewall opens the TLS bag, inspects, and zips it back up before forwarding.
Now the catch. The airport runs two parallel security lines — one is fast (everyone walks through, scanners look for obvious things), the other is slow (full unpack, swab, behavioral profile). T2 calls them domestic vs international. FortiGate calls them flow-based vs proxy-based inspection. Same UTM tools — totally different depth and cost.
Pooja (SOC L2, 14 months in) owns content-inspection rollout for a banking customer's DC perimeter. The customer wants "everything inspected" — web filter, app control, IPS, AV, and now DLP because Compliance escalated a credit-card-leak audit finding from last quarter.
She enabled flow-based mode on the customer VDOM 6 months ago — perf was great, 8 Gbps clean throughput. But yesterday her DLP profile silently stopped firing in FortiOS 7.0. Today she opens a 9.8-rated CVE-2024-21762 IPS alert and her boss asks "is the IPS sig actually blocking, or just monitoring?" Two questions, two profiles, two inspection modes — and a deadline tomorrow. The next 11 minutes are her playbook.
The 90-second mental model
Flow-based inspection reads the packet stream as it passes, pattern-matching in-line. It's fast (NPU-friendly, low memory) and good enough for IPS signatures, basic AV stream-scan, web filter URL lookup, and App Control. Proxy-based inspection buffers the entire object (a file, a full HTTP transaction) in FortiOS memory, reassembles it, scans the full reconstructed object, then forwards. Higher CPU + memory cost, but it's the only way to do full DLP pattern matching, sandbox handoff, and some advanced AV checks.
The interview line you need: "Flow is the default. Proxy is the exception. Pick proxy only when the profile literally cannot work in flow."
Three terms every interviewer will test
Flow-based mode reads the byte stream, fires signatures as patterns match, makes a forward/drop decision per packet. Proxy-based mode buffers the whole transaction in memory before deciding. UTM is just the umbrella name — it's what every interviewer means when they say "security profile".
Default. In-line stream pattern-match. NPU-eligible. ~Wire-speed. Good for IPS, basic AV, web filter, AppCtrl. Cannot do full DLP, some sandbox handoffs (in 7.0/7.2).
Full object buffered in FortiOS memory. Reassembly + deep scan. Required for full DLP (pre-7.4), some advanced AV. Cost: 30-50% throughput drop, NPU bypass.
URL category + static URL filter + FortiGuard rating override. Categories beat individual URLs unless you create an explicit override. Works in both flow and proxy.
L7 fingerprinting. ~7k FortiGuard signatures. Identifies Teams, Zoom, Dropbox, ChatGPT regardless of port. Bandwidth shaping + monitor + block actions per category.
~20k+ signatures. Action per filter: pass / monitor / block / reset / quarantine. Monitor logs but doesn't drop — production rules must use block. Sigs ship within days of major CVE disclosure.
Two DBs: extreme (default) + extended (broader, more CPU). Stream-scan in flow, full-file in proxy. Flow handles known malware fine; proxy needed when you also want sandbox / DLP correlation.
The silent-disable trap — why Pooja's DLP stopped firing
Here is the part that catches even experienced engineers. When you flip a VDOM or policy from proxy-based to flow-based for throughput, FortiOS does not throw an error if a profile can't run in flow — on FortiOS 7.0/7.2 the DLP fingerprint and document-matching features simply stop enforcing. No log line, no alert. The policy looks healthy. The data just walks out.
That is exactly what bit Pooja: six months ago throughput was the priority, so the VDOM went flow-based. The DLP profile was still attached, still "enabled" in the GUI — but the engine that does fingerprint matching needs the proxy to hold the whole object, and in flow mode there is no whole object to hold.
Press Play and watch why proxy mode can do deep DLP and sandbox — and why it costs you the NPU.
report.pdf. In flow mode the FortiGate would scan bytes as they stream — fast, but it never holds the whole file.report.pdf is rebuilt in memory — every byte, in order, exactly as the server sent it.config firewall policy
edit 12
set inspection-mode proxy
next
end
# verify which mode a policy is in
show firewall policy 12 | grep inspection-mode
set inspection-mode proxy
The symptom Pooja saw: DLP profile attached, GUI shows it enabled, but credit-card patterns stop being caught after a move to flow mode — with no error. Always confirm the policy's inspection-mode matches what the profile needs. Pre-7.4, fingerprint DLP and clean sandbox handoff need proxy.
Pooja flips the customer VDOM to flow-based mode for throughput. A week later her DLP profile silently stops catching credit-card patterns — no error, no log. Most likely cause?
Web Filter + App Control — what wins when both fire
Back to the airport. Web Filter is the boarding-pass scan: it judges where you're going — the URL and its FortiGuard category. App Control is the X-ray: it judges what the traffic actually is — the L7 application, regardless of port. New engineers assume one overrides the other. It doesn't work like that.
Rahul (network security L1) gets a ticket: "Marketing can open Google Drive but can't upload files." He checks Web Filter — the File Sharing category is set to allow, so the URL is fine. Then he checks App Control logs and sees Google.Drive.Upload = block. Two profiles, two verdicts, one session. Which one wins?
The answer: they are independent gates, evaluated separately — a block in EITHER one drops the traffic. Web Filter allowed the category, but App Control independently blocked the upload sub-application. There is no "most-permissive wins" vote. Every attached profile is its own checkpoint, and any single block is final.
Web Filter also lets you override a single URL against its category — useful when FortiGuard miscategorises a site your business depends on. The order to remember: a static URL filter entry (allow/block/monitor) is checked before the FortiGuard category rating, so an explicit allow can rescue one site without opening the whole category.
Within an Application Control sensor, a more specific application override beats a broad category action. So you can set the "Video/Audio" category to monitor while explicitly blocking "BitTorrent" — the specific entry wins. Build the exceptions first, the broad strokes last.
A user reaches https://drive.google.com (Web Filter allows the "File Sharing" category) but uploads fail. App Control logs show Google.Drive.Upload = block. Which engine wins, and why?
IPS + AV — monitor vs block, and the CVE-2024-21762 trap
IPS is the behaviour analyst at the airport — it watches the stream for known attack patterns. The single biggest IPS mistake on FortiGate is confusing monitor with block. Monitor logs the match and lets the packet through. Block actually drops it. A sensor full of "monitor" filters generates beautiful dashboards and stops nothing.
The companion engine is AV. In flow it stream-scans for known malware; in proxy it reassembles and scans the whole file, which is what you need for grayware and sandbox handoff. For most user traffic flow-based AV with the extreme DB is plenty.
CVE-2024-21762 is an out-of-bounds write in FortiOS sslvpnd (the SSL-VPN daemon) — unauthenticated remote code execution, CVSS 9.8, on CISA's Known Exploited Vulnerabilities list since Feb 2024. FortiGuard ships an IPS signature for it, but here's the trap: the flaw lives in the FortiGate's own SSL-VPN service. You cannot reliably IPS-protect a box from a vulnerability in its own daemon — the real fix is to patch FortiOS to a fixed build. If you can't patch immediately, disable SSL-VPN, restrict exposure, and hunt for compromise. (PSIRT advisory: FG-IR-24-015.)
config ips sensor
edit "protect-edge"
config entries
edit 1
set severity high critical
set action block
next
end
next
end
# check current content/engine version
diagnose autoupdate versions | grep -A1 "IPS Attack Engine"
IPS Attack Engine Version: 7.x.xxx Contract Expiry: 2026-xx-xx Last Updated: ...
An IPS sensor logs CVE-2024-21762 detections, but Sneha confirms the matching traffic still reached the server. The sensor is attached to the policy. Why didn't it stop the attack?
SSL deep-inspection done right — CA push, pinned certs, exemptions
Most of the airport's "bags" are now sealed — encrypted in TLS. Web Filter can still read the destination from the SNI, but IPS, AV and DLP are blind to the contents unless you open the bag. That's SSL deep-inspection — and it's a controlled man-in-the-middle.
Two modes matter. Certificate-inspection reads only the SNI/certificate — no decryption, no client trust needed, but shallow. Deep-inspection terminates TLS, decrypts, inspects, then re-signs the session with the FortiGate CA and re-encrypts to the client. For that to work, every client must trust the FortiGate CA — push it via GPO (Windows), Intune/Jamf/MDM (Mac, mobile), and a Firefox enterprise policy for the ~5% on Firefox's own trust store.
Certificate pinning is the other half. Banking apps (HDFC, ICICI, SBI YONO), Apple services, some Microsoft activation flows and a few SaaS clients embed the expected issuer in their code. When the FortiGate substitutes its cert, they detect the mismatch and refuse to connect. You don't fight pinning — you exempt it, ideally via the FortiGuard Finance and Banking and Health and Wellness categories plus a small custom list.
config firewall ssl-ssh-profile
edit "deep-custom"
set server-cert-mode re-sign
config https
set ports 443
set status deep-inspection
end
config ssl-exempt
edit 1
set type fortiguard-category
set fortiguard-category 31
next
end
next
end
profile "deep-custom" set · ssl-exempt: 1 entry (fortiguard-category 31)
- CA not pushed: deep-inspection enabled, FortiGate CA missing from clients → every HTTPS site throws a certificate error. Push the CA before you flip the switch.
- Pinned apps not exempted: "the CFO's banking app stopped working" — classic pinning break. Exempt banking/health categories above the deep-inspect rule.
🤖 Ask the AI Tutor
Tap a question — instant, context-aware answer from this lesson. No login.
Pre-curated from Fortinet docs + the FortiGuard PSIRT. For deeper/live questions, ask at chat.techclick.in.
✍ Teach it back
In two lines, explain to a teammate why flipping a VDOM to flow-based mode can silently break DLP. Saying it in your own words is what moves it from "read" to "known".
Frequently Asked Questions
The FortiGate security-profile questions interviewers ask and engineers Google mid-incident.
What is the difference between flow-based and proxy-based inspection on FortiGate?
Flow-based inspects the packet stream in-line as it passes — fast, NPU-eligible, low latency, and the default. Proxy-based buffers the entire object (a file or full HTTP transaction) in FortiOS memory, reassembles it, scans the complete payload, then forwards.
Flow is right for most traffic (Web Filter, App Control, IPS, basic AV). Proxy is the exception for things that need the whole object — full DLP, sandbox handoff, some advanced AV. Expect roughly a 30–50% throughput drop on proxy policies.
When should I use proxy-based inspection instead of flow-based?
Use proxy only when a profile cannot work in flow: full DLP fingerprinting/document matching (pre-FortiOS 7.4), clean FortiSandbox submission, and certain advanced AV/grayware checks. Scope proxy to just those policies — don't switch the whole VDOM, or every flow pays the performance cost.
Why do users get certificate errors after I enable SSL deep-inspection?
Deep-inspection re-signs each site with the FortiGate CA. If that CA isn't trusted by the client, the browser treats every HTTPS site as a man-in-the-middle and shows NET::ERR_CERT_AUTHORITY_INVALID.
Fix it by pushing the FortiGate CA to every client's trust store: GPO for domain Windows, Intune/Jamf/MDM for Mac and mobile, and a separate Firefox enterprise policy (Firefox uses its own store).
Which apps break under SSL deep-inspection, and how do I fix it?
Apps that use certificate pinning — banking apps (HDFC, ICICI, SBI YONO), Apple services, some Microsoft activation flows, certain SaaS and VPN clients. They reject any substituted certificate by design, so they fail behind deep-inspection.
You don't inspect them — you exempt them. Add the FortiGuard Finance and Banking and Health and Wellness categories (plus a small custom domain list) to the SSL exemption list, evaluated above the deep-inspect rule.
What is the difference between SSL certificate-inspection and deep-inspection?
Certificate-inspection only reads the SNI and certificate fields — no decryption, no client-trust requirement, but it can't see inside the payload. Deep-inspection terminates TLS, decrypts, lets IPS/AV/DLP inspect the cleartext, then re-encrypts. Deep-inspection is the only way to inspect content in HTTPS, but it requires the FortiGate CA on every client and breaks pinned apps unless exempted.
My FortiGate IPS shows alerts but isn't blocking the attack — why?
The signature or filter action is almost certainly set to monitor (or left at a pass/monitor default). Monitor logs the match but never drops — "I see alerts" is not "I'm protected". Set the action to block (or reset / quarantine) for anything you want stopped, and confirm the sensor is applied to the correct policy and direction.
If Web Filter allows a site but App Control blocks the app, what happens?
The session is dropped. Web Filter and App Control are independent gates evaluated separately — a block in either one is final. There is no "most-permissive wins"; allowing the URL category does not override an App Control block on the application or one of its sub-functions (like a file upload).
Is a FortiGate IPS signature enough to protect against CVE-2024-21762?
No. CVE-2024-21762 is an unauthenticated RCE in FortiOS's own sslvpnd daemon (CVSS 9.8, on CISA's KEV list since February 2024). You can't reliably IPS-protect a box from a flaw in its own service — the fix is to patch FortiOS to a fixed build immediately. If patching must wait, disable SSL-VPN, restrict access, and hunt for compromise. PSIRT advisory: FG-IR-24-015.
Flow or proxy for DLP and FortiSandbox?
On FortiOS 7.0/7.2, full DLP (fingerprinting/document matching) and clean sandbox handoff need proxy-based inspection because they require the fully reassembled object. FortiOS 7.4 introduced more flow-mode DLP capability, but if you're on 7.2 and your DLP "silently stops working", the usual cause is a policy that was switched to flow mode.
📝 Check your understanding — 10 questions, 70% to pass
Q1–Q3 above already count toward your 10. Below are Q4 to Q10. Pick an answer for each, then Submit.
Which inspection mode is the default for new policies in recent FortiOS — the one you keep unless a profile specifically needs otherwise?
Aditya needs full content DLP with file fingerprinting plus FortiSandbox handoff for email attachments on FortiOS 7.2. Which inspection mode must those profiles use?
Karthik must allow YouTube for the Marketing group but cap its bandwidth, while blocking it for everyone else. Cleanest FortiGate approach?
Right after enabling SSL deep-inspection, every user gets "NET::ERR_CERT_AUTHORITY_INVALID" on all HTTPS sites. Root cause?
After SSL deep-inspection rollout, the HDFC mobile-banking app fails on corporate Wi-Fi while normal HTTPS browsing works fine. Why, and the fix?
5,000 users on a FortiGate 600F: you need Web Filter, App Control, IPS and AV at line rate, plus full DLP only for the Finance VDOM. Best design?
Post-CVE-2024-21762 (unauthenticated SSL-VPN RCE, CVSS 9.8) on a fleet of internet-facing FortiGates, the correct response is:
Glossary — quick reference
- Flow-based: in-line, stream pattern-matching inspection. Fast, NPU-eligible, the default.
- Proxy-based: buffers and reassembles the full object before scanning. Needed for full DLP + sandbox.
- UTM: Unified Threat Management — the umbrella for all security profiles (Web Filter, App Control, IPS, AV, DLP…).
- Web Filter: allows/blocks by URL and FortiGuard category; supports per-URL overrides.
- App Control: identifies the L7 application regardless of port; supports shaping and per-app actions.
- IPS: signature-based intrusion prevention. Action must be block (not monitor) to enforce.
- SSL deep-inspection: decrypts → inspects → re-signs with the FortiGate CA. Requires client trust; exempt pinned apps.
- SNI: the clear-text hostname in the TLS handshake; lets the firewall see the destination without decrypting.
Next up — FortiGate SSL-VPN & IPSec hardening
You've inspected the traffic. Next: secure remote access on FortiGate the right way — SSL-VPN vs IPSec, MFA, and the post-CVE-2024-21762 hardening checklist.
Sources cited inline
- FortiGate 7.4 Administration Guide — inspection modes & security profiles
- FortiGate Admin Guide — Application Control & Web Filter
- FortiGate Admin Guide — SSL/SSH inspection & exemptions
- FortiGuard PSIRT FG-IR-24-015 — CVE-2024-21762
- NVD — CVE-2024-21762 (CVSS 9.8, CISA KEV)
- Fortinet Community — flow vs proxy & DLP behaviour threads