FortiGate: Web Filter + SSL Inspection = Bypass

FortiGate firewalls are widely deployed for perimeter security, and many organizations rely on web filtering to enforce acceptable use policies. However, a common misconception among junior engineers and NSE4 candidates is that web filtering alone protects against unwanted content. When SSL/TLS encryption enters the picture, the interaction between web filter policies and SSL inspection becomes critical. Misconfiguration at this intersection creates a bypass vulnerability that allows encrypted traffic to circumvent content controls entirely.

The Core Problem: Encryption Blinds Web Filters

Web filtering rules in FortiGate operate at Layer 7 (application layer) by inspecting HTTP headers, URLs, and content categories. When traffic is encrypted with SSL/TLS, the firewall sees only the encrypted payload and the destination IP or domain in the SNI (Server Name Indication) field. The actual URL path, query parameters, and page content are invisible. A web filter policy that blocks category 'Streaming Media' cannot enforce that rule on HTTPS traffic unless SSL inspection is enabled and properly chained to the filter policy.

How SSL Inspection and Web Filtering Should Work Together

FortiGate's SSL inspection (also called SSL/TLS inspection or HTTPS inspection) decrypts inbound and outbound encrypted traffic, inspects the decrypted content, and re-encrypts it before forwarding. This decryption must happen before the web filter policy evaluates the traffic. The correct configuration flow is:

• →Create a firewall policy that permits traffic on port 443 (HTTPS)
• →Enable 'Inspect' or 'Deep Inspection' for SSL/TLS on that policy
• →Configure an SSL profile that performs server certificate inspection and optionally applies a local CA certificate to client traffic
• →Attach a web filter profile to the same policy so that decrypted content is evaluated against URL categories, keywords, and file types
• →Ensure the SSL profile is set to 'allow' or 'block' based on certificate validity, not to 'exempt' (which bypasses inspection)

Common Bypass Scenario in NSE4 Labs

A typical lab scenario presents a firewall policy that blocks streaming sites via web filter, but the web filter only applies to HTTP traffic (port 80). HTTPS traffic on port 443 has a separate policy with SSL inspection disabled or an SSL profile set to 'exempt' mode. Result: users can bypass the web filter by accessing the same streaming site over HTTPS. The traffic passes through unexamined, and the web filter rule never sees it.

# Vulnerable configuration (simplified)
config firewall policy
  edit 1
    set name "Allow HTTP with Filter"
    set srcintf "port1"
    set dstintf "port2"
    set srcaddr "all"
    set dstaddr "all"
    set service "HTTP"
    set action accept
    set webfilter-profile "block-streaming"
  next
  edit 2
    set name "Allow HTTPS - NO INSPECTION"
    set srcintf "port1"
    set dstintf "port2"
    set srcaddr "all"
    set dstaddr "all"
    set service "HTTPS"
    set action accept
    # SSL inspection disabled or set to exempt
  next
end

The Correct Fix

Enable SSL inspection on the HTTPS policy and attach the same web filter profile. The firewall will decrypt the HTTPS session, inspect the decrypted content against your web filter rules, and re-encrypt before sending to the client. Both HTTP and HTTPS traffic are now subject to the same content controls.

# Corrected configuration
config firewall policy
  edit 2
    set name "Allow HTTPS with Inspection"
    set srcintf "port1"
    set dstintf "port2"
    set srcaddr "all"
    set dstaddr "all"
    set service "HTTPS"
    set action accept
    set ssl-ssh-profile "deep-inspection"
    set webfilter-profile "block-streaming"
  next
end

One critical detail: SSL inspection requires a valid certificate chain. FortiGate must either trust the destination server's certificate or you must deploy a local Certificate Authority (CA) certificate on client devices to intercept and re-sign certificates. Without proper certificate handling, SSL inspection may fail or trigger warnings that users can dismiss.