debug SSL inspection for flow based vs proxy based traffic

Forum|Forum|3 years ago
September 7, 2023
4 replies
4449 views

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?

FortiGate

Best answer by pminarik

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).

alif

Staff

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).

AkmostafaAuthor

Explorer

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.

spoojary

Staff

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.

pminarikAnswer

Staff

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).

Sign up

Login with SSO

Login to the community

Login with SSO