Description
This article describes that the TLS active probe needs to initiate connections from the FortiGate itself. The few configurations that could trigger the probing requests themselves, such as the SSL profile, which requires SSL exemption or certificate verification, or UTM profile web filter, or the application control enabled. It is essential for the functionality of Application Control and Webfilter, which must apply to verified hostname (SNI) from TLS ClientHello.
The TLS timeout is 5 seconds and cannot be modified.
In cases where the TLS probe fails, the loading time of the web page can be significantly increased (over 5 seconds). The TLS probe can fail due to poor routing in the case of Transparent VDOMs, SD-WAN setup, AWS AGW deployment, or when the secondary IP address is used for Internet access.
Scope
Slow webpage load when the web filter profile is enabled under the policy configuration. For v6.2.6 and above, v6.4.4 and above.
Solution
The IPS Engine daemon is processing this traffic when the policy is in flow mode (by default). It is recommended to start with IPS debugging to identify the slow page load when the Web filter is enabled problem.
IPS Engine debug commands might generate too many logs depending on the inspected session counters. It is highly recommended to enable the debug commands with filters.
To filter the traffic, use the command below ;
diagnose ips filter set
bpf filter bpf filter
This filter is a Berkeley filter which allows to use of many parameters such as source, destination, and TCP/UDP ports.
Example 1:
Filter the traffic from source IP 1.1.1.1 and TCP port 443:
diagnose ips filter set 'src 1.1.1.1 and tcp port 443'
Verify the filter with the command below:
diagnose ips filter status
DEBUG FILTER:
debug level: 17179868671
filter: "host 1.1.1.1 and tcp port 443"
process id: 0
Example 2:
To filter the traffic from source IP 192.168.10.10 and destination IP 8.8.8.8 and port TCP 443:
diagnose ips filter set 'src 192.168.10.10 and dst 8.8.8.8 and tcp port 443'
Verify the filter with the command below:
diagnose ips filter status
DEBUG FILTER:
debug level: 17179868671
filter: "src 192.168.10.10 and dst 8.8.8.8 and tcp port 443"
process id: 0
Example command list for Web Filter debugging:
diagnose debug console timestamp enable
diagnose ips filter set 'src 192.168.10.10 and tcp port 443'
diagnose ips debug enable ssl
diagnose ips debug enable urlfilter
diagnose debug enable
When troubleshooting ends:
diagnose debug disable
diagnose ips debug disable all
diagnose ips filter clear
diagnose debug reset
Open Developer tools on the browser and access the site that is having slowness. Select 'Duration' to sort it by the highest duration. Select the first entry and select Timings. The example below is from Firefox. The TLS Setup is showing around 5 seconds.
Debug output that shows TLS timeout:
2025-10-10 10:24:07 [3463@4911177]on_cb: SSL client fingerprint: 0x33C00FF2924DD179
2025-10-10 10:24:10 [3462@-1]eng_debug_log: Probe info:
2025-10-10 10:24:10 [3462@-1]eng_debug_log: Server: 34.120.78.142:443
2025-10-10 10:24:10 [3462@-1]eng_debug_log: Server name: failed-server.test.com
2025-10-10 10:24:10 [3462@-1]eng_debug_log: STARTTLS: no
2025-10-10 10:24:10 [3462@-1]eng_debug_log: Probe failed: unable to connect
2025-10-10 10:24:10 [3462@-1]eng_debug_log: parallel probes: 16
2025-10-10 10:24:10 [3465@-1]probe_finish: probe finished unsuccessfully. id: 124332, sess: 4910021
In some circumstances, complete information about the probe will not be seen in the debug output.
For example, when many API calls are running towards the destination in question, debug will show only a short message, without the failure detail:
2025-10-10 10:24:10 [3465@-1]probe_finish: probe finished unsuccessfully. id: 124332, sess: 4910021
At the same time, probes could not be seen in a packet capture running in parallel, to confirm that probes leave the firewall:
diagnose sniffer packet any "host 34.120.78.142 and port 443" 4 0 l
This happens because FortiGate does not send a probe for each new initiated flow until the IPS cache keeps a copy of a certificate for the affected server. This certificate is received from a successful original client's TLS handshake.
The cache could be checked with the following commands:
diagnose ips share pool
name | data(B) blocks inuse chunks depth empty(%)
track_none_0 | 64 512 0 0 0 0
track_src_IP_0 | 64 512 0 0 0 0
track_dst_IP_0 | 64 512 0 0 0 0
track_DHCP_client_0 | 64 512 0 0 0 0
track_DNS_domain_0 | 64 512 0 0 0 0
name(MDB) | size(M) entries
expect-0 | 8 0
master_sess_log_table | 8 0
sid_cache | 15 0
cert_verify_cache | 16 0
scert_cache | 16 4
ccert_cache | 8 0
server_cache_0 | 13 7
sip_dialogs | 8 0
exp_bt | 8 0
exp_p2p | 8 0
msrp_expect_cache | 4 0
gtp-u_db | 8 0
tag_cset_db | 8 0
dac_cache | 8 0
cfgobj | 40 65
URLVirusCache | 8 0
dns-client-ip | 8 0
dns-server-ip | 8 0
dns-any-client | 8 0
To expose the server-side certificates list, check the server_cache_0 entry:
diagnose ips share list server_cache_0
SSL Server Cache:
---------------------------------------------------------------------------
...
[00007] server: 34.120.78.14:443
host: 054/9c8512e8, "failed-server.test.com"
CN: "test.com", flags: 0x0003
Cert Hash: 15B7431174133DA096641A8E60ED528750CFFDEA
Inserted: 61 seconds ago
---------------------------------------------------------------------------
To flush the cache and force the firewall to send the probe, execute the following command:
diagnose ips share clear server_cache_0
With the new engine build v7.182, v7.338, and v7.533, if sni-server-cert-check is set to disable, it won't start TLS probe anymore.
That should fix the session delay.
IPSEngine 0182 is the default engine in FortiOS v7.0.16, IPSEngine 0338 in v7.2.9, and IPSEngine 0533 in v7.4.4.
CLI Commands.
config firewall ssl-ssh-profile
edit "custom-certificate-inspection"
config https
set sni-server-cert-check disable
Alternatively, the user can manually configure the outgoing interface, source IP, and VDOM for the IPS TLS active probe connection.
CLI Commands.
config ips global
config tls-active-probe
set interface-selection-method <auto|sdwan|specify>
set interface <intf name> <----- When method 'specify'.
set vdom <vdom name> <----- When method 'sdwan' or 'specify'.
set source-ip <source_ipv4> <----- When method 'sdwan' or 'specify'.
set source-ip6 <source_ipv6> <----- When method 'sdwan' or 'specify'.
set interface-select-method: Specify how to select an outgoing interface to reach the server.
auto <----- Set outgoing interface automatically.
sdwan <----- Set outgoing interface by SD-WAN or policy routing rules.
specify <----- Set outgoing interface manually.
Related articles:
