Skip to main content

 

Cisco Meraki Documentation

Cisco Secure Connect - ZTNA Network Prerequisites & Troubleshooting

  1. Last updated
  2. Save as PDF

ZTNA (Zero Trust Network Access) Prerequisites 

The main prerequisites for ZTNA to work properly are as follows. 

  • Connectivity to the application hosting sites 

  • Routing requirements 

Let’s understand each in detail. 

Connecting application hosting sites to the Fabric: 

There are several possibilities depending on the environment and the deployment of the application.  

  1. If the application is hosted on-prem, appropriate tunnel creation to the Secure Connect Cloud is needed. 

  • If it is a Meraki device, AutoVPN is the fastest possible way 

  • If it is a non-Meraki device, you will need to setup a standard IPsec site to site tunnel.   

  1. If the application is hosted in the Cloud (AWS, Azure, etc.),  recommendation depends on the cloud provider.  

  • If AWS, Azure, Alibaba or GCP Cisco recommends using a vMX with AutoVPN tunnel. This will most match other sites and give you useful troubleshooting tools in the Meraki Dashboard like packet capture. 

  • Other cloud provider a standard IPsec IKEv2 tunnel is supported. 

To learn more about this, please click here. 

Routing requirements: 

  • Our proxy IP Subnet: 

    • 100.64.0.0/10

  • For Meraki routers (MX on-prem), the AutoVPN configuration should share the default route to the Secure Connect hub, which will cover this routing requirement. 

  • The default route for vMX in the Cloud (AWS or Azure) will generally go to the internet via the AWS gateway or Azure Gateway. To make the clientless ZTNA work, you must inject static routes of our proxy blocks that go through the vMX interface instead of the AWS or Azure gateway.   

  • Dynamic routing is not currently available for non-Meraki routers on the Application hosting site. Therefore, for return traffic, the application side router must have a route to our proxy blocks through the backhaul tunnel. 

 

Requirements for Secure Client with Client-Based ZTNA

Devices must meet these requirements in order to use Cisco Secure Client with the Zero Trust Access module:

  • Windows 10 and 11
  • macOS versions 11, 12, 13
  • Windows devices must support Trusted Platform Module (TPM) 2.0
  • Mac devices must support Secure Enclave

For Client-based ZTNA on Mobile device, please refer to the Cisco documentation: Get Started and Manage Client-based Zero Trust Access from Mobile Devices.

Troubleshoot Client-Based Zero Trust Network Access

Pre-Enrollment Errors

Error Description Condition
Cannot begin enrollment Cannot begin enrollment. Contact your IT help desk about these errors. Occurs when there is a KDF, DHA, or TPM error or some combination.
Device registration error An issue with the Device Desktop occurred. Contact your IT help desk. Occurs when Duo desktop is not installed, is not running, or is non-responsive. The user is asked to ensure that the app is running or contact IT help desk for assistance.
Server certification error Error initiating enrollment Client is unable to verify the proxy server certificate.
Cannot connect to DHA   Occurs when the client is unable to communicate with the Device Health application because DHA is not installed.

Enrollment Errors

Error Description Condition
Certification enrollment error   Occurs when the certificate does not install in the background during enrollment. The certificate is required for Zero Trust Access to work properly.
No network connection   Occurs when the user doesn’t have an active or working internet connection (wired or wireless).
User auth error during enrollment Error initiating enrollment. Contact your IT help desk. Occurs when the user has provided an invalid email address or password (or both). The system is unable to verify the user's credentials.

Post-Enrollment Errors

Error Description Condition
Network not allowed Your organization requires you to be on an authorized network to log in. Occurs when a private resource is not configured to allow Zero Trust access. Also occurs when the destination is not a configured private resource, but rather is an IP address that was typed directly into an access rule.
User IP address block Your organization requires you to be on an authorized network to log in. Occurs when the system is configured to allow access only from specific IP addresses, and the user is trying to access private resources from an unapproved IP address.
Application blocked for everyone Location not allowed. Your organization requires you to use a different operating system. Contact your IT help desk. Occurs when the user did not match any rule and was blocked by default or when a rule was not created to allow access to the application.
User blocked implicitly Location not allowed. Your organization requires you to use a different operating system. Contact your IT help desk. Occurs when the user did not match any rule and was blocked by default or when a rule was not created to allow the user access to the application either directly or via a group.
Time-based application block You do not have permission to access this application at this time. Contact your IT help desk. Occurs when the user does not match any rule and was blocked by default or the application does not allow access at this time.
User IP block Location not allowed. Your organization requires you to use a different operating system. Contact your IT help desk. Occurs when the user is using an unauthorized device to access; the user’s credentials aren’t associated with the IP or with that device.
User blocked explicitly Location not allowed. Your organization requires you to use a different operating system. Contact your IT help desk. Occurs when the user is blocked by a rule that denies access or when the user does not have permission to connect or access the resource.
Access protocol block Location not allowed. Your organization requires you to use a different operating system. Contact your IT help desk. User does not have permission to connect to the resource using the current protocol.
User location block Location is not allowed. Occurs when the user did not match any rule and is blocked by default or when the user is not allowed access to the application from their current location.
Cannot connect to DHA   Occurs when there is no response when the client tried to communicate with DHA.

Requests to Reauthenticate

If an end user is offline for an extended time, for example on vacation, Secure Access may prompt the user to reauthenticate in order to restore access to private resources. This is normal and expected.