When the issue occurs, users will be able to initially receive the FortiGate captive portal authentication page, but after submitting credentials, the connection ends with the browser presenting an ERR_EMPTY_RESPONSE message.
Notably, a corresponding Firewall User entry (present in diagnose firewall auth list) will not be created for this device, which means that it will not be able to access resources beyond the FortiGate unless the traffic has already been exempted from captive portal authentication.
See also: Technical Tip: How to configure exemptions for Captive Portal on the FortiGate (captive-portal-exempt and security-exempt-list)>
Root Cause: This issue occurs because of Change 1222371, which was made earlier in FortiOS v7.6.7 and v8.0.0.
This change was meant to give administrators flexibility when it came to handling timeouts for user authentication attempts to the FortiGate, as it changed the authentication timeout from a static 30 second timer to one that is configurable using the auth-portal-timeout setting.
However, this resulted in an unintended side-effect when performing captive portal authentication.
When a user/device attempts to establish connections before completing authentication, those 'pre-authentication' sessions will be tracked by the FortiGate's authd (authentication daemon) process for a time period equal to the time set for auth-portal-timeout.
However, if there are too many sessions accumulating for a given user's IP address, then the authd process will flag it and subsequently drop/disconnect any new sessions arriving from that source. This includes the HTTP POST request that users make when submitting credentials to the captive portal, which is why an ERR_EMPTY_RESPONSE is received after submission.
Notably, this issue can be intermittent, as it depends on how many accumulated sessions are present when the user attempts to authenticate within the auth-portal-timeout period.
Users that authenticate quickly after connecting to the network will be less likely to observe issues than users who take significant time to complete the authentication process, and this issue appears to impact users on an individual (per-source IP address) basis.
Resolution and Workaround:
The issue is under active investigation and is currently targeting a fix schedule of FortiOS v7.6.8 and v8.0.2.
In the meantime, the following workarounds can help significantly reduce the severity of the issue:
Option 1 - Implement the following CLI changes to reduce the likelihood of the issue occurring:
config user setting
set auth-portal-timeout 1
set auth-type http
set auth-secure-http enable
end
The above commands all are aimed at reducing the number of accumulated pre-authentication sessions held by the authd process, which directly reduces (but cannot fully eliminate) the possibility of triggering the issue: Reducing auth-portal-timeout to 1 minute shortens the window in which the authd process holds pre-authenticated sessions. The auth-type option specifies which protocols will trigger captive portal authentication by the authd process. Removing HTTPS from this list prevents HTTPS sessions from triggering the captive portal and being counted as pre-authentication sessions by authd. Enabling auth-secure-http ensures that user/FortiGate authentication is still secured with encrypted HTTPS, rather than plaintext HTTP.
However, users who are already being disconnected/blocked by authd may still continue to do so until the authd process is restarted or a significant amount of idle time has passed. To clear the state of the authd process, either run the command fnsysctl killall authd or use the following alternative restart process:
diagnose sys process pidof authd
diagnose sys kill 15 <PID>
diagnose sys process pidof authd
Note:
In the above command, <PID> must be replaced with the first number returned by the first instance of diagnose sys process pidof authd. The second instance of this command is run after restarting the authd process and should report a new set of process ID numbers.
Option 2 - Rollback to an unaffected firmware version:
If the issue is still occurring after implementing Option 1, then it may be necessary to roll back to an unaffected firmware version, such as FortiOS v7.6.6 or any earlier branch (such as v7.4).
Where possible, use the FortiGate's alternate partition system to safely rollback to the immediate-previous installed firmware, and consult the following documents for more information: Technical Tip: Selecting an alternate firmware for the next reboot Technical Tip: Best practices for firmware upgrades and downgrades | 
