| Description | This article describes how captive portal operates in FortiGate and FortiProxy. |
| Scope | FortiGate, FortiProxy. |
| Solution |
There are two official ways for web page traffic to be redirected to different page, either with HTTP redirect codes (301, 302, 307, and 308) or with JavaScript that will initiate a new request for a different webpage. For its regular captive portal, FortiGate uses the second method and it does so by intercepting the HTTP GET request to the web server, and returns an HTTP code 200 with JavaScript that instructs the browser to open a new tab and reach the captive portal.
Nowadays, most of the web traffic is handled by Transport Layer Security(TLS). The TLS bulk encryption makes it impossible for a FortiGate between the client and server to identify the HTTP GET requests. Moreover, asymmetric encryption prevents FortiGate from intercepting TLS packets and replying on behalf of the server. Software developers of browsers and operating systems recognize the need of captive portals and the limitations that TLS causes to the implementation of one. For that reason, unencrypted HTTP requests to 'vendor specific URLs' are generated on the background when a client connects to a network (in the Operating System case) or opens when a browser opens. An example of these URLs is 'gstatic.com/generate_204' for Google Chrome, 'www.msftconnecttest.com/connecttest.txt' for Microsoft Edge, etc.
On the other hand, FortiProxy (and explicit proxy on FortiGate) use the HTTP redirect codes (more specifically code 303 See Other) because, from the client perspective, it is the web server. |
