Security · 4 min read

FortiGate NSE4 Lab: Application Control Bypass – Policy Trap

A common misconception in FortiGate deployments is that enabling Application Control in a firewall policy automatically blocks unwanted applications. In reality, traffic often bypasses these controls due to policy logic, inspection mode misconfigurations, or rule ordering. This lab walks through the exact scenario where application control fails and how to diagnose and fix it.

The Policy Trap: Why Application Control Silently Fails

FortiGate evaluates firewall policies in order, from top to bottom. The first matching policy wins. If a permit policy sits above your application control policy, traffic is allowed before application inspection even occurs. Additionally, application control requires Deep Packet Inspection (DPI) to be enabled at the policy level, and the inspection mode must be set to a profile that actually blocks or monitors the application category.

Many engineers enable Application Control but leave the action set to 'Monitor' instead of 'Block', or they fail to attach an Application Control profile that contains the application they want to restrict. The result: traffic flows freely while logs show no violations.

Lab Scenario: The Missing Block Rule

Imagine a policy that permits all HTTP and HTTPS traffic from the internal network to the internet, with no application control. Later, you add a second policy meant to block YouTube. The problem: the first policy matches before the second one is evaluated. YouTube traffic is already allowed.

config firewall policy
  edit 1
    set name "Allow-All-HTTP-HTTPS"
    set srcintf "port1"
    set dstintf "port2"
    set srcaddr "all"
    set dstaddr "all"
    set action accept
    set schedule "always"
    set service "HTTP" "HTTPS"
    set nat enable
  next
  edit 2
    set name "Block-YouTube"
    set srcintf "port1"
    set dstintf "port2"
    set srcaddr "all"
    set dstaddr "all"
    set action accept
    set schedule "always"
    set service "HTTP" "HTTPS"
    set apptype "youtube"
    set utm-status enable
    set application-list "default"
  next
end

Policy 1 matches and allows the traffic. Policy 2 never runs. The fix: reorder policies so that restrictive rules come first, or consolidate into a single policy with proper application control.

Correct Configuration: Application Control First

config firewall policy
  edit 1
    set name "Block-YouTube"
    set srcintf "port1"
    set dstintf "port2"
    set srcaddr "all"
    set dstaddr "all"
    set action accept
    set schedule "always"
    set service "HTTP" "HTTPS"
    set utm-status enable
    set application-list "block-streaming"
  next
  edit 2
    set name "Allow-Other-HTTP-HTTPS"
    set srcintf "port1"
    set dstintf "port2"
    set srcaddr "all"
    set dstaddr "all"
    set action accept
    set schedule "always"
    set service "HTTP" "HTTPS"
    set nat enable
  next
end

Now the blocking policy is evaluated first. When YouTube traffic arrives, it matches policy 1, the application control profile inspects it, identifies YouTube, and blocks it. Subsequent traffic that is not YouTube matches policy 2 and is allowed.

Key Verification Steps

Understanding port numbers and service definitions is also critical. Many application control bypasses occur because traffic uses non-standard ports. Refer to your port reference guide to confirm which ports your target application actually uses, then ensure your firewall service definitions or application profiles match.

Common Port Reference
Free tool to verify standard and non-standard ports for applications and services
Open →
Practise this on today’s Daily Ops Drill — a free network task every day.
Open the app →
Free tools for this
More from the blog
FortiGate: Web Filter + SSL Inspection = BypassRead →Juniper VLAN Range in Filter: Expansion and Matching OrderRead →