Random AnyConnect FALSE captive portal issues....

[Pete Johnstone]

This happened to a remote employee of one of my client's, all of a sudden the AnyConnect client starting giving this (bogus) error (it's bogus because this happened at their home, where they have connected fine for many months):

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.

Ultimately the only way I was able to get rid of this, was completely uninstall the AnyConnect software, make sure all traces were deleted, and reinstall.

Well, it just happened to me at my home (where I've also never had a problem).  Same error message, I was connected and all of sudden disconnected and this error....I'm assuming at this point there is something wrong with their ASA device (5505) config.

The documentation I've found only talks about why this happens when it is "supposed to happen", as opposed to these bogus "false positives" which I haven't found a solution for.  Any ever have these issues and managed to figure out what is going on?  I really don't want to have to keep making housecalls to remote folks and I anticipate this will continue to happen until I figure out why it is happening.

[JP Miranda Z · Accepted solution]

Hi Pete Johnstone,

I have seen this many times, you can take a look to the following documentation:

False Captive Portal Detection

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

• If AnyConnect attempts to contact an ASA with a certificate that contains an incorrect server name (CN), then the AnyConnect client will think it is in a captive portal environment.
  
  In order to prevent this issue, make sure that 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 that 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 in order to connect to the ASA.
  
  If you must 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) in order to ensure that HTTP/HTTPS requests sent to the ASA will not return an unexpected response.

AnyConnect Behavior

This section describes how the AnyConnect behaves.

1. AnyConnect tries an HTTPS probe to the Fully Qualified Domain Name (FQDN) defined in the XML profile.
   
   
2. If there is a certificate error (not trusted/wrong FQDN), then AnyConnect tries an HTTP probe to the FQDN defined in the XML profile. If there is any other response than an HTTP 302, then it considers itself to be behind a captive portal.

Also you have the option of removing the captive portal detection on AnyConnect versions 4.2.00096 and later:

Disable the Captive Portal Feature

It is possible to disable the captive portal feature in AnyConnect client version 4.2.00096 and later (see Cisco bug ID  CSCud97386). The administrator can determine if the option should be user configurable or disabled. This option is available under the Preferences (Part 1) section in the profile editor. The administrator can choose Disable Captive Portal Detection or User Controllable as shown in this profile editor snapshot:

If User controllable is checked, the checkbox appears on the Preferences tab of the AnyConnect Secure Mobility Client UI as shown here:

http://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/118086-technote-anyconnect-00.html#anc5

Hope this info helps!!

Rate if helps you!!

-JP-