Users unable to VPN into our network using Planes/Hotel/Coffee shop WIFI

rhamersley
Getting noticed

Users unable to VPN into our network using Planes/Hotel/Coffee shop WIFI

Is there a setting in the Cisco Secure client XML profile to allow users able to log into a Planes/Hotel/Coffee Shop's WIFI portal then allow the "Always On" Cisco Client feature to then allow the user to VPN into the network.   All our users are able to successfully use their "HotSpots" on their phone to connect to the VPN but not the locations WIFI (Plane/Hotel/Coffee Shop).

 

Has anyone else experiencing this issue currently?

4 Replies 4
alemabrahao
Kind of a big deal
Kind of a big deal

To connect to a VPN over a public Wi-Fi network may also depend on the network’s own settings and restrictions, which can vary widely. Some networks may block VPN connections entirely.

 

 

In other words, it doesn't seem to be an application problem but something on the network that may be limiting.

 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Marvin_
Here to help

Hi rhamersley,

Is connect failure policy closed on your your client?

Then captive portal remediation must be enabled to connect to wifi with captive portals.

I hope this article can help you fixing your problem:

https://www.cisco.com/c/en/us/td/docs/security/vpn_client/anyconnect/Cisco-Secure-Client-5/admin/gui...

thaack
Getting noticed

 

Allow captive portal remediation

Many facilities that offer Wi-Fi and wired access, such as airports, coffee shops, and hotels, require the user to pay before obtaining access, agree to abide by an acceptable use policy, or both. These facilities use a technique called captive portal to prevent applications from connecting until the user opens a browser and accepts the conditions for access.

If always-on VPN is enabled, the connect failure policy is closed, captive portal remediation is disabled, and Anyconnect detects the presence of a captive portal, the AnyConnect GUI displays the following message once per connection and once per reconnect:

“The service provider in your current location is restricting access to the Internet.”

“The Anyconnect protection settings must be lowered for you to log on with the service provider. Your current enterprise security policy does not allow this.”

Captive portal detection is enabled by default, and is non-configurable

Captive portal remediation is the process of satisfying the requirements of a captive portal hotspot to obtain network access. By default, the connect failure policy prevents captive portal remediation because it restricts network access. You can configure AnyConnect to lift restricted access to let the user satisfy the captive portal requirements. You can also specify the duration for which the client lifts restricted access

If the connect failure policy is open, users can remediate captive portal requirements. The captive portal remediation feature applies only if the connect failure policy is closed and a captive portal is present.

 

KB Article 

PhilipDAth
Kind of a big deal
Kind of a big deal

Going sideways.

 

"Always on" sounds great in practice, right?  At least it does to me.

However in daily use it tends to be problematic.  Nearly every client I have deployed this at gets me to turn it back off again.

 

For what it is worth, everyone gets me to deploy SAML based authentication these days.  The two most common ones I do are directly against AzureAD/EntraID or Cisco Duo.

Get notified when there are additional replies to this discussion.