FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
krajaa
Staff
Staff
Article Id 198382

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.

 

2025-01-06 09 47 32.png

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:

Troubleshooting Tip: How to collect HAR files

Troubleshooting Tip: IPS engine new debug commands