Internet Explorer displayed "page could not be displayed" exception and Chrome and Firefox both pointed to redirect loop and gave the uri responsible. This was the http://virtualURL?QueryString returned in the 302 location header. Basically the transparent auth redirect.
What should then happen is that the client then makes a GET /?QueryString with the host of the virtual url. It did do this but then the proxy responded with another 302 and so on so you basically had a redirect loop.
What should then happen is that the blue coat sends a 401. We never saw this.
The policy was initially origin ip redirect. We changed this to auto so it would do origin cookie redirect to rule out a surrogate issue. What was weird was that the page would be displayed after refreshing the browser.
We found that the client's laptop had two interfaces enabled. They had a layer guard on the auth layer for certain ip ranges. They also had no auth policy for
certain ip subnets. The wireless and lan nic were of course in different subnets. We disabled the wireless nic so that the box only had the one ip address. Once we did this no IP REDIRECT LOOP.
The issue would have been caused by the origin ip redirect surrogate however the no auth policy for certain subnets was also to blame since the issue still occurred after setting cookie surrogate. Basically requests were going out both interfaces causing a redirect loop.