Blocked Nodes are not redirected to CWP page
============================================

With all systems utilizing Captive Portal technology, there are some inherent
issues that are present due to the underlying protocols and functionality
associated with a Captive Portal environment.
This document will discuss the most common issues and available workarounds.

Symptom 1
---------

**Certificate Warnings**

The first issue is certificate warning messages being displayed to the end user
upon a Captive Portal redirect. Language may vary but typically a message
similar to "Your connection is not private" may be displayed to the end user as
a warning. This issue is well known in Captive Portal environments and is the
expected behavior. 

Cause 1
-------

The cause of this issue is the technology that is used during a Captive Portal
redirect for an HTTPS website.

The diagram below depicts the flow when a host accesses an HTTPS website when
no Captive Portal is present:


  .. image:: /images/communication-https.jpg
    :width: 600px

HTTPS communication requires intercommunication between the Web Server and the
PC for encrypted communication before creating a cryptographic session.

#. Client hello: PC notifies Web Server of HTTPS communication request
#. Server Hello, Certificate: The server passes the certificate to the client,
   the client determines that the certificate is a trusted certificate
#. Client Key Exchange: The client sends the pre-master-secret key to the Web
   Server, Symmetric key sharing
#. Finish: After the end of the negotiation process, communication is exchanged
   by a symmetric key exchange


After that, encrypted communication is established between the PC and Web
Server using the encrypted channel.

For comparison, the diagram below depicts the flow when a host accesses an
HTTPS website when a Captive Portal is present:

  .. image:: /images/mitm-attack.jpg
    :width: 600px   
    
The important point here is that the server certificate is transmitted to the
CA certificate (FAKE Certificate) of the Captive Portal system so that the
encrypted communication is not connected to the original target Web Server,
but instead the session is established with the Captive Portal Web Server.

Resolution 1
------------

For the reasons listed above, end users must acknowledge the certificate
warning, typically by clicking “Continue” before being redirected to the
Captive Portal page.

Most modern operating systems now have built-in Captive Portal detection
capability. Windows 10 Captive Portal Detection, Apple Captive Network
Assistant and Android Connectivity Manager are all examples of this feature.
These features function by sending out HTTP requests to various URLs
pre-defined at the OS level to determine if the device is behind a Captive
Portal. If no response is received, it is assumed the device is behind a
Captive Portal.  At that point, the operating system will automatically
invoke an HTTP request using the default browser. Because the request
is HTTP and not HTTPS, Captive Portal redirection occurs without any issues.

Captive Portal detection in general is not a perfect science,
however, ensuring all packets are blocked the moment a device
connects results in a higher probability of Captive Portal detection
functioning properly, thereby bypassing the issue of certificate warnings.
Genian NAC is constantly improving features and a new feature is being
implemented which should ensure that the majority of the time endpoint
device Captive Portal detection is triggered.
This document will be updated with additional information when the feature is
available.

Symptom 2
---------

**HSTS Websites – Browser Does Not Allow Redirect**

What is HSTS? 
At a high level HSTS (HTTP Strict Transport Security) is a policy that, when
enabled, forces a browser to use an HTTPS connection over a HTTP and allows
for the SSL certificate to be cached on the browser for a predetermined length
of time. With HSTS enabled, clients are protected from protocol downgrading,
man in the middle attacks (which is what a Captive Portal redirection is) and
cookie hijacking. 

Cause 2
-------

Most modern browsers (Google Chrome, Mozilla Firefox, Microsoft Edge) come
preloaded with a list of sites supporting STS (Strict Transport Security).
Once enabled a timeout will be sent with the HTTPS header that contains a HSTS
TTL “Strict-Transport-Security: max-age=31536000” (one year). The certificate
received from the site will be honored until the timeout expires. Future
attempts to access the site will reference the certificate and, if the
certificate does not match, the browser will not allow the connection to
site to be established. For users behind a Captive Portal, this is where
they reach a dead end because accepting a certificate warning will not allow
them to proceed.

Resolution 2
------------

For users visiting an HSTS website behind a Captive Portal the only option is
to browse to a non-HSTS website. Therefore, when enabling a Captive Portal for
the first time in a new environment, it is key to communicate to end users to
visit a particular website (perhaps the organization’s website as long as it
is not HSTS) if they are unable to access the other websites. This will allow
users to be redirected to a captive portal properly. Some organizations even
setup a specific page for this purpose (onboard.company.com,
register.company.com, etc) and notify users in advance.

Symptom 3
------------

**CWP redirection fails in environments using Proxy Server**

.. note:: Starting with version 5.0.53 (LTS), CWP Redirect has been enhanced to operate even when connecting via Proxy.(#25704)

Cause 3
----------

Captive portals may not be able to provide proper redirection if internal hosts on the network are configured to use a proxy server.

Resolution 3
----------------

By making the proper proxy exceptions on your proxy server, this will ensure captive portal redirection functions properly.

See: :doc:`/onboarding/configuring-cwp` for info on creating proxy server exceptions.