Anyconnect 3.1 Captive Portal False Alert Stops Users Connecting.

[CSCO11950572]

Hi All,

I am having problems with a customer's ASA 5505 with Anyconnect 3.1 - it is generating captive portal false-alerts which are stopping users from connecting.

This issue began when I upgraded from Anyconnect 2.4 to 3.1, and it appears like this: A user downloads and installs the Anyconnect client and is able to connect fine, to begin with. However, once they reboot their computer and try to reconnect, the VPN session will not come up and they receive the error message below.

"The service provider in your current location is restricting access to the internet. You need to log on with the service provider before you can establish a VPN session. You can try this by visiting any website with your browser."

Reading other posts, it seems this message appears when a captive portal is restricting internet access. It must be a false alert in this case as there is nothing of the sort here. Apparently, Anyconnect 3.1 can generate a false alert like so if the name of the firewall's SSL certificate doesn't match the CName listed on the Client Profile. I've set this up to match, to no avail.

Although users can connect by reauthenticating through the SSL VPN login web page, I am stumped as to how to get rid of this captive portal error that pops up when they try to use the Anyconnect client.

Any advice would be appreciated, just let me know what extra details to post if needed.

Many thanks,

Josh Campbell

[Tarik Admani]

Just out of curiosity where are the users connecting from? Also have you tried to export the DART bundle after this issue occurs?

Thanks,

Sent from Cisco Technical Support iPad App

[CSCO11950572]

Hi,

They're connecting from their homes, so straight out through an access point or modem.

I don't have DART installed, but here are summaries of several events that Anyconnect logged in Windows Event Viewer while I tried to connect - they show a little more detail than the bare Anyconnect-exportedstats.txt file. Earliest event is on top and these are consecutive:

3/01/2013 4:15:39 p.m.

The HTTPS probe to 121.73.25.204 resulted in a redirect.

3/01/2013 4:15:39 p.m.

Description: CERTIFICATE_ERROR_VERIFY_POLICY_FAILED:Certificate failed a policy check

server name: 121.73.25.204

3/01/2013 4:15:39 p.m.

Description: NETENVIRONMENT_ERROR_CERT_VERIFICATION_FAILED:The server cert verification performed after the HTTPS probe has failed

3/01/2013 4:15:39 p.m.

Captive portal detected. Retesting connectivity to the secure gateway in 10 seconds.

This chain of events goes on to repeat itself several times per logon attempt.

Thanks,

Josh

[Tarik Admani]

Josh,

Your best bet is to try to install the self signed certificate to the machines trusted CA store or if you were planning to use a 3rd party certificate you may want to try that. Much like yourself I think this maybe an issue with the message on the client displaying incorrectly. Also if you can try to pull a packet capture try to see if the http probe isnt being redirected.

It does seem as if dns is working but try to install the dart bundle and see if you can any more messaging on this issue.

Sent from Cisco Technical Support iPad App

[Srikanth K. S · Accepted solution]

Hi Joshua,

The below information could be located at

www.cisco.com/en/US/docs/security/vpn_client/anyconnect/anyconnect31/administration/guide/ac03vpn.html

False Captive Portal Detection

AnyConnect can falsely assume it is in a captive portal in the following situations.

•If AnyConnect attempts to contact an ASA with a certificate containing an incorrect server name (CN), then the AnyConnect client will think it is in a "captive portal" environment.

To prevent this, make sure the ASA certificate is properly configured. The CN value in the certificate must match the name of the ASA server in the VPN client profile.

•If there is another device on the network before the ASA, and that device responds to the client's attempt to contact an ASA by blocking HTTPS access to the ASA, then the AnyConnect client will think it is in a "captive portal" environment. This situation can occur when a user is on an internal network, and connects through a firewall to connect to the ASA.

If you need to restrict access to the ASA from inside the corporation, configure your firewall such that HTTP and HTTPS traffic  to the ASA's address does not return an HTTP status. HTTP/HTTPS access to the ASA should either be allowed or completely  blocked (also known as black-holed) to ensure that HTTP/HTTPS requests sent

There is also a bug filed for this. Just for your reference,

CSCud17825 - Anyconnect captive portal

Regards,

Srikanth K S.