Skip to main content
Cisco Meraki Documentation

Cisco Secure Connect - Client-less Remote Access (ZTNA)

  1. Last updated
  2. Save as PDF

Overview

Client-less Remote Access or Browser Access allows you to leverage a web browser for user authentication and application access without requiring users to install the client on their devices. This is currently limited to web-based applications. Client-less remote access can simplify how users access private applications while working remotely. It also provides a solution to situations such as the following:

  • Control user access to applications on devices with operating systems that Cisco Secure Client does not currently support.
  • Provide third-party access to your private applications on devices that might not be owned or managed by your company (e.g., contractor or partner-owned devices)

Each user and device is verified and validated by a Browser Access Policy before access is permitted to an application or resource. The verification is granular per session. Users have the freedom to connect from anywhere with any policy-compliant device.

Architecture of Clientless Remote Access (ZTNA) 

clipboard_e658e30b8ee1ee57a5f71e056ba3f463b.png

Clientless Remote Access is a turnkey as-a-service solution. As shown in the diagram above, the customer environment will establish connectivity to Secure Connect fabric. The Edge traffic will be acquired by Secure Connect fabric via Service Edge. Service edge works as a proxy and connects to secure connect services as well as authentication services. The Secure Connect fabric can route traffic to the application as the interconnection establishes. 

The following are the high-level responsibilities of each block. 

Customer Edge  

  • The client initiates a browser connection to the application-specific URL 

  •  This request gets resolved and redirected to the nearest Datacenter based upon AnyCast DNS 

Service Edge  

  • The Datacenter knows which service to reach out to from the connection request 

  • Connects to the nearest Umbrella cloud where the service is running and proxies the traffic coming from the browser 

Fabric Services  

  • The ZTNA Proxy changes the traffic source to an address within 100.64.0.0/16 or 100.127.0.0/16 (carrier grade NAT range) 

  •  A request is sent for authentication and posture check 

  • Once authenticated and authorized, it will redirect the request to the policy engine, where the decision is made to let the request in or not based on your set policies 

  • Once decided, it will be sent to our routing engine to deliver traffic to the application correctly 

Customer Environment  

  • The user has secured access to the application 

Prerequisites

The main prerequisites for clientless remote access to work properly are as follows. 

  • Identity configuration 

  • Connectivity to the application hosting sites 

  • Routing requirements 

Let’s understand each in detail. 

Identity configuration: 

Clientless remote access method relies on two key aspects: Authentication and Authorization. Hence Identity configuration is a necessary part of Client-less Remote Access to work. Please click here to learn how to set up an identity provider in the Secure Connect dashboard. 

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, depending on the cloud provider and the connector being used in the Cloud,  

  • If AWS and vMX, AutoVPN tunnel is a way to go 

  • If AWS, Azure, GCP, or any other cloud provider, standard IPsec or SLVPN from the respective cloud provider’s gateway or virtual firewall is appropriate. 

To learn more about this, please click here. 

Routing requirements: 

  • Our proxy IP blocks: 

    • 100.64.0.0/16
    • 100.127.0.0/16 

  • 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. 

Configuring Browser Access Policies 

Once all prerequisites are met, follow the Application configuration and Browser Access Policy creation process outlined below. 

Step 1: Application configuration 

To configure an application for browser-based access, please follow the steps outlined here. 

Step 2: Posture Profile configuration: 

Please follow the steps outlined here to configure a posture profile for browser access policies. 

Step 3: Browser Access Policy:   

  1. Navigate to Secure Connect->Policies-> Browser Access Policy
  2. In the upper right corner, click +Add Rule
  3. In the Name window, type a Name for the rule
  4. Select an Action, Allow or Deny
  5. Select Group and/or Users

clipboard_e5f4949e72864b31461216969a4df7a4b.png

  1. Choose the Applications and/or Application Groups evaluated with this policy or click the Private application to add a new application.

  1. (Optional) Select a Posture Profile

  1. Click Save