Technical Tip: Raw TCP and FTP traffic bypassing Application Control on an HTTP-only policy
Description
This article describes how to restrict non-HTTP traffic on a FortiGate policy that relies on an Application Control profile to enforce an 'HTTP-only' restriction.
A policy configured with a broad Service field (for example, ALL or ALL_TCP) together with an Application Control profile that blocks every category except HTTP/TLS can still allow raw TCP traffic (verified using netcat, including an interactive reverse shell) and FTP traffic through.
This occurs because Application Control's ability to block 'everything except HTTP/TLS' depends on FortiGate successfully fingerprinting the Layer 7 protocol from the session payload.
When a session carries no recognizable application-layer signature, FortiGate does not classify it as unknown-application. Instead, it falls back to labeling the session generically as tcp/<port> (a generic-TCP classification).
This generic-TCP label is treated as a known protocol rather than an unknown one, so it does not trigger the profile's Unknown Application Action, and it is not blocked by a profile that only blocks named non-HTTP/TLS categories.
Scope
FortiGate.
Solution
To restrict non-HTTP traffic on FortiGate:
Go to Policy & Objects -> Firewall Policy and edit the policy in question (for example, the policy corresponding to Rule ID 810).
Set the Service to HTTP, HTTPS (ports 80 and 443) instead of a broad service such as ALL or ALL_TCP. This is the key step; it prevents non-HTTP(S) ports from reaching the policy at all, regardless of how Application Control subsequently classifies the payload.
Verify that the Application Control profile applied to the policy (for example, http-protocol) is configured to block all categories except HTTP/HTTPS/TLS.
Under the Application Control profile, verify that Unknown Application Action is set to Block. Note that this alone does not close the gap described above, because unfingerprinted raw TCP/FTP sessions are labeled as generic-TCP rather than unknown-application, and generic-TCP is not subject to this setting.
Test the configuration to confirm that non-HTTP traffic (for example, a netcat session on a non-standard port) is being blocked, and that HTTP/HTTPS traffic still passes as expected.
Additionally, it is recommended to split traffic into dedicated policies by service/port rather than relying on a single broad policy plus Application Control to define what is and is not permitted. Restricting the Service field on each policy ensures traffic is scoped correctly at Layer 4, independent of Application Control's Layer 7 classification behavior.
For FTP specifically, be aware that the control channel (port 21) and the dynamically negotiated data channel (active or passive mode) are separate sessions. Restricting the Service field as above blocks both, but if Application Control alone is relied upon, the data channel session can be subject to the same generic-TCP fallback behavior as raw TCP.
Note:
Versions 5.0 up to 7.2 are out of engineering support. So these commands might be different on higher versions.
Consider upgrading the firmware level on the device to a supported version (7.4 up to 7.6). Please check the firmware path and compatibility depending on the hardware on the following Upgrade tool.
