Cisco 9800 Captive Portal Re-Direct to External Web Server

[KatoNakatomi]

Replacing existing WLC5508 with WLC9800 (17.3.3). Using same Guest WiFi with existing external captive portal server.

End users devices connecting to the Guest WiFi for the first time are redirected to the external but the external portal is not displayed on the devices. When users disconnect from the Guest SSID and reconnect the re-direct is successful and captive portal page is displayed.  The captive portal redirect works for a period, however when user come back the following day and try to connect again they experience the same issues.

WebAuth

External Web Server: http://portal.company.com/wifiportal

Web Auth intercept HTTPs: not enabled

      WLAN Security L3 (no pre-auth ACLs applied at this time)

END USER EXPERIENCE IS ON FIRST TIME TO CONNECT TO THE GUEST SSID THE EXTERNAL WEB AUTHENTICATION REDIRECT FAILS. WE DO NOT SEE THE HTTP REQUEST FROM THE CLIENT ON THE WIRED NETWORK THROUGH THE END USER DEVICE IS REQUESTING, ie SYN but NOT SYN ACK. THE PACKET IS NOT BE PASSED BY THE WAP TO THE WIRED NETWORK. HOWEVER, IF USER DISCONNECTS FROM SSID AND THEN RECONNECTS THE CAPTIVE PORTAL REDIRECT IS SUCCESSFUL!

Subsequent connections works once you disconnect and reconnect to the Guest SSID

Potential bug:  CSCvy91799:Flex local-sw COS-APs not plumbing preauth ACL for first client connection attempt for CWA and EWA (CSCvy77144). Known Affected Releases: ap-17.3.3.26

SOLVED: Upgraded to 17.3.4 Release

[Grendizer]

Do you have “no ip http server” configured on the 9800?

Does the Web server respond from one and only one IP Address or from pool of IPs?

[KatoNakatomi]

Yes we have "no ip http server" but

parameter-map type webauth global

 webauth-http-enable

https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-3/config-guide/b_wl_17_3_cg/m_vewlc_sec_webauth_cg.html#d217521e3249a1635.

As for the external Web Server its fronted by a load balancer.

It works no problems on original WLC5508, only experiencing this problem with the new WLC9800 that we are migrating to.

[Grendizer]

Ok, so If you want to use multiple servers to do external WebAuth as in this case, use bypass ACL as below example, in below example, we have DNA Spaces returning two IPs for the portal, sometimes 52.55.235.39 and sometimes 34.235.248.212 so if you add just one IP in WebAuth Parameter this will create two ACLs that you can't change (WA-sec-IP_ADDRESS and WA-v4-int-IP_ADDRESS) but with bypass ACL as in below you will solve this problem and you will get the portal always (just remember to replace and add all your IPs here:
ip access-list extended BYPASS_ACL2
deny ip any host 52.55.235.39
deny ip any host 34.235.248.212
exit
parameter-map type webauth global <-- has to be global or 9800 will not take it
webauth-bypass-intercept BYPASS_ACL2
Another way to do it is by using URL filter, for DNA Spaces for example we're using splash.dnaspaces.eu and splash.dnaspaces.io instead of the above method and use this URL filter with the policy profile but in case you can't use URL filter then you have the bypass ACL option.

[KatoNakatomi]

Thanks for the response, I should have clarified, we only have a single web authentication portal IP Address of a load balance across the whole environment. 

[Grendizer · Accepted solution]

Regarding the bug you listed, I have tested External WebAuth with ISE and DNA Spaces with 17.3.3 and 17.3.4 and couldn’t see the problem, but I didn’t test that with FlexConnect, do you have this problem with local or Flex APs?

Also, this bug is not hitting 17.3.2 so if you want to validate that you’re hitting this bug you can try to downgrade to this code (if you’re still in test environment for the migration)

[KatoNakatomi]

We are using Flex Connect (central auth \ local switching).

We were advised by Cisco TAC on another issue to upgrade to 17.3.3. 

[Grendizer]

Ok, then likely you did hit this bug, if you need to confirm it, take a debug from the AP itself:
debug client xx:xx:xx:xx:xx:xx
debug capwap client payload
debug capwap client detail
debug capwap client flex
debug capwap client acl
debug flexconnect event
then check the debug for below log:
chatter: client_ip_table :: ClientIPTable:Client (xx:xx:xx:xx:xx:xx) not found for webauth
solution or fix for the bug is available with escalation image (not available yet on Cisco Website) to get that image, ask TAC to provide you that image or wait till next public release of 17.3.4 because that will include it too.

[KatoNakatomi]

Thank you, I have a case with TAC .  We are seeing a lot of this chatter for affected client MAC address. 

• Aug 12 13:10:20 kernel: [*08/12/2021 13:10:20.2340] chatter: client_ip_table :: ClientIPTable:Client (6A:5A:AA:49:BF:9D) not found for webauth
• Aug 12 13:10:20 kernel: [*08/12/2021 13:10:20.2340] chatter: client_ip_table :: ClientIPTable:Client (6A:5A:AA:49:BF:9D) not found for webauth

[alintadimitri]

Yes we have "no ip http server" but

parameter-map type webauth global

webauth-http-enable

https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-3/config-guide/b_wl_17_3_cg/m_vewlc_sec_webauth_cg.html#d217521e3249a1635.