Dear team,
Is true that regardless of policy type (flow / proxy), when enabling deep inspection, the traffic is handled in a proxy manner because two connections are open (one from client to Fortigate where Fortigate signs a certificate and present it to the client , and the other session is from Fortigate to the destination internet server?
I have tried to debug a connection using diagnose debug wad, but no output is presented on the console until I changed the policy type to proxy.
So what is the application/process debug that can be turned on in case if troubleshooting ssl deep inspection?
Solved! Go to Solution.
On the TLS level, the session is most certainly "proxied" regardless of the inspection mode, since there are two distinct TLS sessions: client<->FGT, FGT<->server. So in a way you are correct with the initial point.
However, in flow-mode the TCP session is left unmodified as much as possible (i.e. same TCP options in SYN/SYN-ACK) and inspected by IPS engine, whereas in proxy-mode this will be wad and truly separate TCP sessions (optionally up to the point that the client must first finish a TCP handshake with the FortiGate, and only then will the FortiGate establish a TCP session with the destination server).
hi @Akmostafa
In proxy-based inspection, 'wad' daemon handles proxy inspection on the Fortigate (explicit proxy and firewall policy in proxy mode inspection).
In flow-mode inspection, IPS engine is doing flow based scanning. The firewall policies with SSL deep-inspection enabled in flow-mode uses IPS engine for handling the flow traffic (you can say some kind of mini-proxy within the IPS engine).
Thanks that has been helpful.
I have tried the "diag ips debug" and got some output.
However, what is the difference between the above debug and the below:
diag debug application ipsmonitor
diag debug application ipsengine
Thanks.
When troubleshooting or monitoring IPS (Intrusion Prevention System) on a FortiGate device, these commands come in handy, but they serve slightly different purposes:
diag ips debug: This is a general debug command to view the current operation of the IPS system. It can show you how the IPS signatures are being applied to your traffic, and give a real-time view of IPS activity.
diag debug application ipsmonitor: The ipsmonitor
is more about the IPS monitoring process itself. It provides insight into the status, updates, and health of the IPS engine. If you suspect issues with the updates or the state of the engine, this is where you'd look.
diag debug application ipsengine: This debug command pertains to the core IPS engine. It provides detailed logs about the operations, detections, and actions taken by the IPS engine. It's more granular than diag ips debug
and can give deeper insights into the workings of the engine, the signatures being matched, and so on.
On the TLS level, the session is most certainly "proxied" regardless of the inspection mode, since there are two distinct TLS sessions: client<->FGT, FGT<->server. So in a way you are correct with the initial point.
However, in flow-mode the TCP session is left unmodified as much as possible (i.e. same TCP options in SYN/SYN-ACK) and inspected by IPS engine, whereas in proxy-mode this will be wad and truly separate TCP sessions (optionally up to the point that the client must first finish a TCP handshake with the FortiGate, and only then will the FortiGate establish a TCP session with the destination server).
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1859 | |
1133 | |
769 | |
447 | |
263 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2025 Fortinet, Inc. All Rights Reserved.