Timeout with Webauth

[Bodo Bellut]

Hi,

I'm running into issues with the Guest network in one site. Apparently, clients run into timeouts when going to the Webauth login page.

The WLC runs several sites with several APs in the same Guest AP group, however only this one site reports the timeout issues.

The initial redirect works fine, but the virtual IP (1.1.1.1) doesn't seem to respond, so it's neither a DHCP nor DNS fault.

Going directly to https://1.1.1.1/login.html runs into the same timeout. This affects several clients with different OSes, Androis, iOS, Windows.

Ping tests from the clients to the virtual IP 1.1.1.1 get no response. Clients stay in WEBAUTH_REQD until the disconnect after a while.

However, one client is able to connect just fine.

I've done some debugs on the WLC but "debug client <MAC>" does not show a single log message. Unfortunately, the code on this WLC is 7.0.223.6 and getting approval for an upgrade is very challenging to say the least.

Any ideas what could cause this or sugegstions how to further troubleshoot this?

Thanks and regards.

[Konstantin Kabassanov]

Did you try to wireshark on the client side? It should allow you to see if there are any strange packets or if you are near the max mtu. And of course if packets are really sent to 1.1.1.1 on port 443...

[Bodo Bellut]

I have asked for a packet capture to be run, haven't heard back from them, yet.

On a similar note, is there a way to ping/traceroute/telnet into the CAPWAP tunnel from an LWAP?

[Sandeep Choudhary]

increase the client user idle timeout to 1800 and session timeout to 65535.

https://rscciew.wordpress.com/2014/05/07/timeout-setting-on-wireless-lan-controller/

Clinet user idle and session timeout is under Advanced tab on WLAN.

Regards

Dont forget to rate helpful posts

[Bodo Bellut]

Thanks, but looks to be an SSL handshake issue. See my reply above.

[Bodo Bellut]

I've received a Wireshark trace and this clearly shows the initial HTTP conversation works fine and the redirect to the login page is sent. The client sends its SSL Client Hello packet but never gets an SSL Server Hello in return.

This bug from 2014 roughly matches the symptoms but at least implies all clients affected and not just some:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsz89858

I have attached the SSL handshake attempt below.

[Konstantin Kabassanov]

It seems to be a network issue (wireless or wired)... Packet 2 is resent in packet 9 because controller did not receive corresponding ack... And I wonder if Client Hello packets reach th controller. There should be a way to debug on the controler side...

Did you try: debug web-auth redirect enable mac d8:fc:93:49:ae:21

and debug web-auth webportal-server enable ?

[Bodo Bellut]

I'm not convinced this is a network error. You can see the 3 way handshake happening without issues and the initial HTTP conversation (not included in the uploaded file for privacy reasons) also worked fine.

There are no retransmissions in the full trace except for the SSL Client Hello suggesting the server is receiving but ignoring them. Dropping exactly these 6 Client Hello packets while forwarding all other packets in the network is highly unlikely.

Unfortunately, the code on this WLC does not support your suggested debugs and the debug client MAC filter does not apply to all messages which poses the risk of impacting the WLC.

I've tried "debug emweb server enable" which nearly crashed the WLC...

I have requested a maintenance window to try and reboot the WLC and also suggested a code upgrade (which is in order anyway for a myriad of security advisories) but experience shows this is extremely challenging.

[Bodo Bellut]

This has been resolved by Cisco TAC enabling "Fast SSID Change" on the WLC.