I’m seeing strange behavior on the WLAN at one location. This location is one of many that are on the same controller and identically configured, save for AP locations and IP addresses. No other site is reporting this problem. Here’s my problem description:
Users report that many devices are unable to access “any site that requires a login”. From what I’ve seen, this really means most (but not all) SSL protected URLs. HTTP URLs work fine, HTTPS URLs timeout. This only happens on the open guest SSID. If one connects to the secured corporate SSID, everything works normally. Reports indicate that many, but not all devices are impacted. We couldn’t find a single Apple device that was impacted, but on-site staff believes it hits some of them, too. One of the staff owns an Android phone on which the problem is reproducible. I’m heading out there tomorrow with a suite of test devices to see if I can duplicate it with any of them. There is a possibility it only hits 802.11ac devices, but this is not the only 802.11ac site and it is the only one reporting this problem. I have connected with an 802.11ac laptop and had no issues. The 2.4GHz RF environment leaves something to be desired (and was the source of the Spectrum Analysis as Art post), but this problem also occurs on 5GHz. The APs are in FlexConnect mode, so I tried switching them to local mode and that did not change the behavior.
Does this sound like anything someone has seen? Any ideas what is going on?
FIN
It sounds like something is doing a MITM on the https traffic with the client not complaining about the certificate for some reason. The symptom sounds really similar to when someone accidentally turns on https deep inspection on a PaloAlto or Fortnet box. Many big web properties are setup to block something like that from happening, even if you get the client to trust the cert that the MITM box is using. I highly doubt it’s something on the wireless side of things but just that the impacted network is generally only accessed via wireless. Look for something transparently or L3 inline with the guest network but not the corporate SSID or firewall rules that do something different for that network.
Would be cool to wire shark it and see what’s happening with those https packets although since they work on the corp SSID and not on your public, my gut tells me to look at the controls in place for public connections.
There are no controls and guest access is centralized with all site using the same central link. Yet this is the only site complaining…
So, it turned out not to be a Wi-Fi problem. It was a problem with the WAN eating the CAPWAP packets, which is why it only manifested itself on the guest SSID. It also was strange because it only was obviously broken for Linux-based clients.