On Sat, Aug 3, 2013 at 7:30 PM, Matthew Thompson <matthewbot at gmail.com> wrote: > openconnect v5.01 gives the following error when connecting to my > university's vpn, vpn.ufl.edu: > > [matthewbot at gas-powered-stick openconnect]$ openconnect https://vpn.ufl.edu/ > POST https://vpn.ufl.edu/ > Attempting to connect to server 128.227.166.118:443 > SSL negotiation with vpn.ufl.edu > Connected to HTTPS on vpn.ufl.edu > Got HTTP response: HTTP/1.0 302 Temporary moved > POST https://ssrb230a-vpn-asa5500-1-g10-1.ns.ufl.edu/ > Attempting to connect to server 128.227.166.117:443 > SSL negotiation with ssrb230a-vpn-asa5500-1-g10-1.ns.ufl.edu > Connected to HTTPS on ssrb230a-vpn-asa5500-1-g10-1.ns.ufl.edu > Got HTTP response: HTTP/1.0 302 Object Moved > GET https://vpn.ufl.edu/ > SSL negotiation with vpn.ufl.edu openconnect sure goes through a lot of redirects when connecting to this gateway. It would be good to try out the official Cisco client and see if this behavior is expected. > However, some publicly available SSL testers don't report any issues > with the certificate, and indeed, the error goes away in openconnect > v5.00. I haven't had time to look at the code yet, but I did > successfully bisect the problem to commit > 152d4e4a296984a538d7d6b52a18b24ce32bffdb, "When falling back to > non-xmlpost, revert to original URL." I'm hazarding a guess that > something about the specific sequence of redirects used by my > university is breaking the logic introduced in this change? Or is > something actually wrong with our SSL setup? Thanks for the > assistance. Your SSL setup looks OK. What I saw was that openconnect actually connected to ssrb230a-vpn-asa5500-1-g10-1.ns.ufl.edu when it thought it was connecting to vpn.ufl.edu. Could you please try my patch and indicate whether it fixes the problem for you? Thanks.
