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
endPolicy 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
endNow 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
- →Check policy order: use 'show firewall policy' and verify restrictive rules are listed first.
- →Confirm utm-status is 'enable' on the policy applying application control.
- →Verify the application-list profile exists and contains the applications you want to block.
- →Check that the action is set to 'accept' (not 'deny') so the policy is evaluated; the profile determines the block.
- →Review logs: 'diagnose debug flow trace enable' and 'tail traffic.log' to see which policy matched.
- →Test with a known application: curl or wget to a known YouTube URL should be logged and blocked if configured correctly.
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.