08-28-2019 04:24 AM - last edited on 02-24-2020 11:20 AM by Monica Lluis
I'm working with a customer that has WSA deployed in transparent mode, using WCCP to intercept and redirect traffic to the WSAs. They complained that https://www.speedtest.net/ doesn't work. Upon loading, the website performs a latency check and shows a status message, 'Finding optimal server', which ultimately times out (approx 10secs) and then redirects the user to an error screen stating that there's network latency issues.
As part of my troubleshooting, I tried explicitly configuring the WSA as the proxy server in Internet Options. With the WSA explicitly configured, https://www.speedtest.net/ loads normally and works 100% (desired result).
I understand that the HTTP Headers clients send are different between the two WSA implementation modes, I'm just trying to understand the specifics of why, this issue is happening.
I'm hoping to be able to resolve the issue to allow the customer to continue using a transparent WSA deployment with https://www.speedtest.net/ working as normal.
Solved! Go to Solution.
09-09-2019 04:41 PM
Thanks for your reply Ash.
Sorry for not updating this sooner. I ended up going to TAC for this issue and it's now resolved.
The solution from TAC:
Regarding the speedtest.net, it looks like it is sending non-HTTP traffic on a HTTP port. By default, non-HTTP traffic is not allowed. We can change the setting and see if the BLOCK_ADMIN_TUNNELING is still generated. Please do the following :
From the CLI:
> advancedproxyconfig
> MISCELLANEOUS
Would you like to permit tunneling of non-HTTP requests on HTTP ports?
[N]> y
>commit
08-28-2019 03:52 PM
Hello
Are you facing the problem only for https://www.speedtest.net/ or other url's as well in transparent mode?
Would you be able to give me the access logs when you try and connect to https://www.speedtest.net/ ?
I would also recommend you take to take a pcap on the WSA when you initiate the traffic.
Regards
Ash
09-09-2019 04:41 PM
Thanks for your reply Ash.
Sorry for not updating this sooner. I ended up going to TAC for this issue and it's now resolved.
The solution from TAC:
Regarding the speedtest.net, it looks like it is sending non-HTTP traffic on a HTTP port. By default, non-HTTP traffic is not allowed. We can change the setting and see if the BLOCK_ADMIN_TUNNELING is still generated. Please do the following :
From the CLI:
> advancedproxyconfig
> MISCELLANEOUS
Would you like to permit tunneling of non-HTTP requests on HTTP ports?
[N]> y
>commit
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide