Users are unable to connect to VPN while traveling on plane/hotel to our Meraki MX using AnyConnect

rhamersley
Getting noticed

Users are unable to connect to VPN while traveling on plane/hotel to our Meraki MX using AnyConnect

Users are unable to VPN into our Meraki MX security appliances with captive portal set to false.   If we open captive portal we open our company to a vulnerability.   Is there anyway around or any additional fixes to get around to allow users access to Hotels/Plane hotspot to allow VPN access into our Meraki environment.

7 Replies 7
rhamersley
Getting noticed

Will I need to enable "DisableCaptivePortalDetection" to allow users access to hotel/plane hotspots to allow for VPN connectivity even if I have "AlwaysOn" enabled?   

Has anyone else run into their employees that travel have trouble accessing hotel/plan hotspots while using the "AlwaysOnVPN" enabled for their XML profile?

rhamersley_1-1715018844464.png

 

 

 

thaack
Getting noticed

Yes, especially if you have always on enabled. Related KB Article 

 

If Always-On is disabled, or if Always-On is enabled and the Connect Failure Policy is open, the following message is displayed on each connection attempt:

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.

The end user must perform captive portal remediation by meeting the requirements of the provider of the hotspot.

If Always-On is enabled and the connect failure policy is closed, captive portal remediation needs to be explicitly enabled.

If we open captive portal we open our company to a vulnerability. How so?

FWIW, always on VPN causes more trouble than it's worth most of the time.

 

PhilipDAth
Kind of a big deal
Kind of a big deal

I don't understand your problem.

You have a user on a plane trying to use AnyConnect.  How does your captive portal relate to the issue?

BlakeRichardson
Kind of a big deal
Kind of a big deal

Most public Wifi requires you to login using a captive portal before any traffic is passed, if your users are simply connecting to the wifi SSID and not authenticating then yes their VPN connection will not work. 

Always on VPN doesn't work well in these environments as the VPN connection and the portal can get in the way of each other sending you in a loop. 

Disable always on VPN and teach your users how to manually connect. 

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.
rhamersley
Getting noticed

In our environment everyone is set to "AlwaysOn" configuration for their VPN access.   

So to clarify and to answer my question it is not possible for users to access Plane WIFI or Hotel WIFI if we have "AwaysOn" configured in our Cisco Secure Client XML profile.

There has to be a way to allow users connect to hotspots at hotels and planes with the "AlwaysOn" configured and then allow Cisco Secure Client complete the VPN process.

thaack
Getting noticed

You need to configure captive portal detection/remediation depending on your connect failure policy.

If you have:

  • Always-on enabled
  • The connect failure policy is closed
  • Captive portal remediation is disabled (default in always on environments)

Users will be unable to connect if a captive portal is detected.

If you have:

  • Always on enabled
  • Connect failure policy set to open

You do not explicitly need to allow captive portal remediation and the end user will be required to remediate the captive portal.

If you have:

  • Always on enabled
  • Connect failure policy set to closed
  • Captive portal remediation explicitly allowed in the VPN profile

End user will be allowed to remediate captive portal.

Related Documentation 

 

MlatParl
Here to help

I have:

  • Always on enabled
  • Connect failure policy set to closed
  • Captive portal remediation explicitly allowed in the VPN profile

But captive portal is always not allowed...

Users cannot reach the public hotspot website identification...

The only way to fix my problem is to change the login failure policy to open...

Get notified when there are additional replies to this discussion.