SSLVPN in IE 8 or 9 does not display login page

Answered Question
Mar 22nd, 2012

Hi all,

I have a working setup with a customer using UC560 that uses SSLVPN and it works but only when using other browsers like Firefox and google chrome, when we try using IE version 8 or 9 we get prompted about the security certificate (the usual, as it's https) and after making the exception it does not display the login page, just this: Internet Explorer can't display this website, and that's about it, don't even get the chance to login nor download the anyconnect client, anyone know if there's a patch or something for this?

I have this problem too.
0 votes
Correct Answer by GuyllFyre about 1 year 9 months ago
I have  managed to track down the problem of IE not being able to connect to the webvpn  portal.

Microsoft  Security Patch KB2585542 - http://support.microsoft.com/kb/2585542 is  the cause.

Microsoft Security Bulletin MS12-006 - Important

Vulnerability in SSL/TLS Could Allow Information Disclosure  (2643584)

Published: Tuesday,  January 10, 2012 | Updated: Wednesday, January 18, 2012

http://technet.microsoft.com/en-us/security/bulletin/ms12-006

Removing  this patch allows IE to connect to the SSLVPN portal.

The question  now becomes, should we remove this patch or should people using it have  Chrome or FireFox installed as an alternative instead?
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (1 ratings)
jasbryan Tue, 03/27/2012 - 08:38

Eric,

Strange but let's make sure it's not settings on SA500

log into SA500 and look under administration-->Users now click on edit user polices by browser make sure you don't have deny IE as a rule. This is the only setting on our routers that would block what you are referring too. If user polices are not configured then this would be a problem with your IE browser itself. It could be security settings or IE could be corrupt. It's hard to say since you have control over you IE browser settings.

Jasbryan

Eric Hernandez Tue, 03/27/2012 - 11:41

Hi Bryan,

thanks for your response, unfortunately it's a UC560 not an SA500 so i don't have those options, so far I haven't found configuration options that deny IE or someting like that, it really is a weird problem and it's though to troubleshoot.

When I do debug webvpn http and try to enter the webpage with IE it shows this:

077696: Mar 26 19:35:09.841: WV-HTTP: Fragmented header-line

077697: Mar 26 19:35:09.841: WV-HTTP: HTTP request line too long

077698: Mar 26 19:35:09.841: WV-HTTP: Deallocating HTTP info

and when i do the same debug but enter the webpage using firefox or google chrome it succeeds, sending this debug output:

102796: Mar 27 18:37:02.411: WV-HTTP: Original client request

GET / HTTP/1.1

user agent is:Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Ge

102797: Mar 27 18:37:02.411: WV-HTTP: HTTP Header parsing complete

102798: Mar 27 18:37:02.411: WV-HTTP: * HTTP request complete

102799: Mar 27 18:37:02.431: WV-HTTP: Original client request

GET /webvpn.html HTTP/1.1

user agent is:Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Ge

102800: Mar 27 18:37:02.431: WV-HTTP: HTTP Header parsing complete

102801: Mar 27 18:37:02.431: WV-HTTP: * HTTP request complete

102802: Mar 27 18:37:02.515: WV-HTTP: Original client request

GET /paramdef.js HTTP/1.1

user agent is:Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Ge

102803: Mar 27 18:37:02.515: WV-HTTP: HTTP Header parsing complete

102804: Mar 27 18:37:02.515: WV-HTTP: * HTTP request complete

102805: Mar 27 18:37:02.523: WV-HTTP: Original client request

GET /lang.js HTTP/1.1

user agent is:Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Ge

102806: Mar 27 18:37:02.523: WV-HTTP: HTTP Header parsing complete

102807: Mar 27 18:37:02.523: WV-HTTP: * HTTP request complete

102808: Mar 27 18:37:02.547: WV-HTTP: Original client request

GET /shared.js HTTP/1.1

user agent is:Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Ge

102809: Mar 27 18:37:02.547: WV-HTTP: HTTP Header parsing complete

102810: Mar 27 18:37:02.547: WV-HTTP: * HTTP request complete

102811: Mar 27 18:37:02.671: WV-HTTP: Original client request

GET /img/logo.gif HTTP/1.1

user agent is:Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Ge

102812: Mar 27 18:37:02.671: WV-HTTP: HTTP Header parsing complete

102813: Mar 27 18:37:02.671: WV-HTTP: * HTTP request complete

102814: Mar 27 18:37:02.675: WV-HTTP: Original client request

GET /img/login_photo.jpg HTTP/1.1

user agent is:Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Ge

102815: Mar 27 18:37:02.675: WV-HTTP: HTTP Header parsing complete

102816: Mar 27 18:37:02.675: WV-HTTP: * HTTP request complete

102817: Mar 27 18:37:02.895: WV-HTTP: Original client request

GET /favicon.ico HTTP/1.1

user agent is:Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Ge

102818: Mar 27 18:37:02.899: WV-HTTP: HTTP Header parsing complete

102819: Mar 27 18:37:02.899: WV-HTTP: * HTTP request complete

102820: Mar 27 18:37:02.907: WV-HTTP: Original client request

GET /webvpn.html HTTP/1.1

user agent is:Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Ge

102821: Mar 27 18:37:02.907: WV-HTTP: HTTP Header parsing complete

102822: Mar 27 18:37:02.907: WV-HTTP: * HTTP request complete.

I wonder what difference do they have in the HTTP request line length, probably a browser problem, I'll keep looking into it like it's the browsers fault for now.

giuseppe-dimarco Sun, 06/03/2012 - 09:41

Hi Eric,

you have solved it???

i have the same problem with SR520 router

it works with firefox (but i have problem to download anyconnect for full tunnel)  but nothing with ie9.

Thanks

Giuseppe

Eric Hernandez Mon, 06/04/2012 - 06:46

Hi Giuseppe,

sadly I haven't been able to fix this, TAC guy said it was a browser problem and they can't do anything about it, so the customers have been using google chrome or firefox to login to the ssl vpn and establish the vpn connection. I also tried tweaking around the IE configuration in Tools > Internet Options > Advanced options, in the security settings but no success, I've practically given up on that.

Correct Answer
GuyllFyre Fri, 06/29/2012 - 06:44
I have  managed to track down the problem of IE not being able to connect to the webvpn  portal.

Microsoft  Security Patch KB2585542 - http://support.microsoft.com/kb/2585542 is  the cause.

Microsoft Security Bulletin MS12-006 - Important

Vulnerability in SSL/TLS Could Allow Information Disclosure  (2643584)

Published: Tuesday,  January 10, 2012 | Updated: Wednesday, January 18, 2012

http://technet.microsoft.com/en-us/security/bulletin/ms12-006

Removing  this patch allows IE to connect to the SSLVPN portal.

The question  now becomes, should we remove this patch or should people using it have  Chrome or FireFox installed as an alternative instead?
Eric Hernandez Fri, 06/29/2012 - 09:35

That's amazing!! How did you manage to find that out Sean? I removed the patch just to try it out and it really works, I will let the customers know and it's up to them which option to use, FireFox/Chrome or remove the patch and use IE. Many people are determined to use IE or just don't know any better but I don't really know if there's any risk with that SSL/TLS Vulnerability when removing thet patch. Anyways, that's great Info Sean thanks a lot.

GuyllFyre Fri, 06/29/2012 - 10:46

We have just set up a new data center with other health centers and are using Cisco ASA products with the SSL VPN.

We experienced the same problem with the Cisco SSL VPN web logon page when working through a new support document, we could get IE to get to the point of asking about the certificate but it then would go no further.

Google searches related to the SSL VPN showed other products having a similar issue and one of them determined that the patch in question caused it.

Following up a little, the following article linked in that KB article explains it a bit more;

http://support.microsoft.com/kb/2643584

Down in the article it says the following:

Known issues with this security update

After you install this security update, you may experience  authentication failure or loss of connectivity to some HTTPS servers.  This issue occurs because this security update changes the way that  records are sent to HTTPS servers.

Now that we know which patch and change to IE causes the problem, hopefully Cisco will update their firmware/IOS to fix the issue and regain the ability to use fully patched IE with their SSL VPN.

Actions

Login or Register to take actions

This Discussion

Posted March 22, 2012 at 11:40 AM
Stats:
Replies:7 Avg. Rating:5
Views:3125 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard