| Description | This article describes an expected behavior where a FortiGate operating in NGFW policy-mode will issue a TCP RST to block a connection, rather than issue a block page that shows the details for why a user's web connection was blocked. On the user's web browser, the difference will manifest as an ERR_CONNECTION_RESET or PR_CONNECT_RESET_ERROR rather than a block page being displayed. |
| Scope | FortiGate, NGFW policy-mode |
| Solution |
The above behavior can occur intermittently if the following conditions are met:
The following example Security Policies where Policy 1 matches and allows traffic based on Application Signature (in this case YouTube), and the next Policy 2 below matches and denies traffic based on the News and Media URL Category:
Application ID 31077: YouTube config firewall security-policy edit 1 set name 'Allow_Application' next edit 2 set name 'Block_URL_Category' next end
In this scenario, traffic that should be blocked by Security Policy 2 ('Block_URL_Category') may be blocked by a TCP RST, rather than the client seeing a block page that explains the block decision. This behavior is somewhat random, in that some websites may consistently see a block page being presented by the FortiGate, and other websites may only see a ERR_CONNECTION_RESET or PR_CONNECT_RESET_ERROR error in the web browser.
The reason this occurs is because the IPS Engine has to defer the block decision (based on matching the URL Category-based policy) until enough session data has been analyzed to confirm if the traffic should actually match the allowed application or not.
This behavior is partially determined by how quickly the IPS Engine can match a website to a given Application Signature. Some websites like cnn.com have dedicated Application Control signatures, and so the IPS Engine can more-quickly identify these applications. Traffic to cnn.com would be quickly scanned by the IPS Engine (does not match YouTube signature, does match News and Media Category) and because the traffic was detected quickly enough a block page can be successfully issued to the end-user.
However, most other websites (like cbc.ca) do not have dedicated Application Signatures, and so the IPS Engine will take longer to scan the traffic and match against a less-specific signature (such as the SSL family of signatures), even if it has already received a URL Category verdict from FortiGuard. This longer scanning time requires the IPS Engine to defer the block decision until enough session data is captured to rule out the possibility of the traffic belonging to an allowed application.
After a certain scan range is exceeded, the IPS Engine will discard the Application-based Security Policy and will block the traffic based on the URL Category-based Security Policy. However, this blocking is occurring much later in the traffic flow, typically at the point where the IPS Engine is receiving reply data from the server side. Due to a limitation with the IPS Engine SSL stack, the IPS Engine is not able to insert a block page into the server-reply data, and therefore, the only alternative is to issue a TCP RST for the connection. This results in the end-user seeing an error page in the web browser, like the following:
Workaround: Option 1: Create custom Application signatures: Creating Custom Application Signatures A custom Application Signature would allow the IPS Engine to match applications more quickly, which in-turn would allow the policy matching process to complete more quickly and allow for a block page to be issued in time.
Option 2: Request official Application Signatures from the FortiGuard IPS team: FortiGuard Application Signature Request Similar to Option 1, the FortiGuard team is constantly adding new signatures for Application Control to allow for faster and more granular application matching. |
