I find in wireless a lot of people aren’t familiar with Fiddler. I was introduced to Fiddler when I was writing web services and needed to diagnose why my web services weren’t working. Fiddler is a web proxy for windows that runs under the .Net framework. (Sorry Mac users). I think to think of Fiddler as Wireshark for Web Services. While you can proxy for other devices, that’s beyond the scope of this article.
One of the things I have the most difficult with is troubleshooting Captive Web Portals. There are a lot of things that can go wrong. Between DHCP, DNS and Web Intercept, external web servers, etc, it can be especially difficult to troubleshoot to narrow down where the issue is.
Layer on top of this things like on-boarding product or RADIUS Change of Authorization, Cloud services and content filtering, things can become very complicated in a hurry. While Fiddler doesn’t make it any simpler, it does give us the visibility to the web interactions between the client and server.
I’ll assume that you’ve gone over to www.fiddler2.com and downloaded/installed the software. It’s free. I would suggest installing it on a windows laptop with a fresh install. Why? Just because you won’t have a million apps trying to make calls to cloud services while you’re troubleshooting.
So I launch fiddler on my broken Web Auth wireless network and try to go to www.google.com. Care to guess why this isn’t working?
.png)
Hmm, DNS Lookup Failed. Although, since I broke the DNS server for this example, I know this is why and after the DNS issue is resolved, this is what we get.
Looking at the response you can see there is a Web Auth Redirection and the the Virtual IP of the WLC. Prettying this up we see:
Web Authentication Redirect
If you click on the subsequent entries, you can look at both the client request and response. If you are doing HTTPS, you can even enable HTTPS decryption so you can see what is going into the tunnel, which is something that’s a lot harder to do with low level tools like Wireshark.
Encrypted HTTPS traffic flows through this CONNECT tunnel. HTTPS Decryption is enabled in Fiddler, so decrypted sessions running in this tunnel will be shown in the Web Sessions list.
Secure Protocol: Tls
Cipher: Aes256 256bits
Hash Algorithm: Sha1 160bits
Key Exchange: RsaKeyX 1024bits
== Server Certificate ==========
[Subject]
CN=192.0.2.1, OU=DeviceSSL (WebAuth), O=Cisco Systems Inc., C=US
[Issuer]
CN=192.0.2.1, OU=DeviceSSL (WebAuth), O=Cisco Systems Inc., C=US
[Serial Number]
00E51A9CE1
[Not Before]
7/8/2013 6:00:01 PM
[Not After]
7/8/2023 6:00:01 PM
[Thumbprint]
F1064A5A9811A241F09A42C822CBDE6E2D59BEF8
With SSL Decryption in place, you can actually look and see that it didn’t work this time because my username and password were not correct. Now be aware that to do this, i have to accept the fiddler SSL cert and approve each tunnel to decrypt, so for a hacking/sniffing tool, it’s not very useful.
Now while Fiddler is a good tool to have in your arsenal, it won’t replace packet capture software for other troubleshooting. You also might find uses for this outside of the wireless world. My coworker uses this for testing with load-balancers and other higher layer services. So happy Fiddling and hopefully you find this tool useful.
ToDSFromDS 