The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Configuring Layer 3 Security Using Web Authentication
To initiate HTTP/HTTPS web authentication redirection, use HTTP URL or HTTPS URL.
If the CPU ACLs are configured to block HTTP / HTTPS traffic, after the successful web login authentication, there could be a failure in the redirection page.
Before enabling web authentication, make sure that all proxy servers are configured for ports other than port 53.
When you enable web authentication for a WLAN, a message appears indicating that the controller forwards DNS traffic to and from wireless clients prior to authentication. We recommend that you have a firewall or intrusion detection system (IDS) behind your guest VLAN to regulate DNS traffic and to prevent and detect any DNS tunneling attacks.
If the web authentication is enabled on the WLAN and you also have the CPU ACL rules, the client-based web authentication rules take higher precedence as long as the client is unauthenticated (in the webAuth_Reqd state). Once the client goes to the RUN state, the CPU ACL rules get applied. Therefore, if the CPU ACL rules are enabled in the controller, an allow rule for the virtual interface IP is required (in any direction) with the following conditions:
The allow rule for the virtual IP should be for TCP protocol and port 80 (if secureweb is disabled) or port 443 (if secureweb is enabled). This process is required to allow client’s access to the virtual interface IP address, post successful authentication when the CPU ACL rules are in place.
When clients connect to a WebAuth SSID and a preauthorization ACL configured to allow VPN users, the clients will get disconnected from the SSID every few minutes. Webauth SSIDs must not connect without authenticating on the web page.
If multiple identity stores are selected, then the controller checks each identity store in the list, in the order specified, from top to bottom, until authentication for the user succeeds. The authentication fails, if the controller reaches the end of the list and user remains un-authenticated in any of the identity stores.
WLANs can use web authentication only if VPN passthrough is not enabled on the controller. Web authentication is simple to set up and use and can be used with SSL to improve the overall security of the WLAN.
This section describes the two scenarios that clients can encounter when a WLAN is configured to use web authentication along with 802.1x.
Client associated to a single controller—In this scenario, when the reauthentication or PMK cache timer expires, the client reauthenticates, updates the reauthentication/PMK cache timer and remains in the run state. When the client session timer (ST) expires, the client is deauthenticated even if the reauthentication/PMK cache timer is still valid.
Client roams from one controller to another controller—In this scenario, after the client roams the foreign controller triggers an L2 authentication and the anchor controller triggers an L3 authentication. The 802.1x reauthentication/PMK timer runs on the foreign controller and the client session timer runs on the anchor controller. When the reauthentication/PMK timer expires, 802.1x client reauthentication happens and the client is in the run state. Client is deauthenticated only when the client session timer expires.
Note | We can have same or different users for both 802.1x and web authentication. |
Configuring Web Authentication