Welcome back to our exploration of modern zero trust technologies! In this entry, we're going to pull back the curtain on Cisco Secure Access and examine how Zero Trust Network Access (ZTNA) client traffic steering actually works under the hood. If you've been wondering how your private applications and internet traffic know which path to take through the Secure Access cloud, you're in for a treat. We'll dive into the provisioning of Private Resources (SPA) and Internet Resources (SIA) in the Secure Access Portal, how those configurations make their way down to the Secure Client Zero Trust Access module, and finally how traffic gets intercepted at the socket level for tunneling back to the appropriate proxy. Buckle up!

What is Zero Trust Client Traffic Steering?

Before we get into the nitty-gritty details, let's establish what we're talking about here. Zero Trust client traffic steering is the mechanism by which the Cisco Secure Client determines whether a particular connection should be routed through Secure Private Access (SPA) for internal resources, Secure Internet Access (SIA) for web traffic, or neither (direct connection). Think of it as an intelligent traffic cop sitting on your endpoint, making split-second decisions about where each connection should go.

The magic happens through a combination of centrally managed policies (configured in the Secure Access portal) and locally cached steering configurations on the endpoint. When you attempt to connect to ise.example.com or browse to google.com, the Zero Trust Access module has already figured out the appropriate path for that traffic. But how does it know? That's what we're here to uncover!

The Big Picture - From Portal to Endpoint

The journey begins in the Secure Access portal where administrators define their Private Resources and Internet Resources. These configurations get transformed into JSON steering rules, pushed down to enrolled endpoints, cached locally, and then used to make real-time traffic steering decisions. Let's walk through each phase of this process.

Private Resources (SPA) and Internet Resources (SIA) Configuration

In the Secure Access portal, administrators configure two primary types of resources that define what traffic should be steered through the zero trust proxy infrastructure.

Private Resources (Secure Private Access) encompass your internal corporate applications and services. These might include internal web applications like SharePoint sites, domain controllers, file servers, or that critical business application that only lives on the corporate network. When you define a private resource, you're essentially telling the system "this traffic should be routed through our SPA proxy so users can access it securely from anywhere."

Internet Resources (Secure Internet Access) represent the broader internet traffic that you want to inspect, filter, or secure through your SIA proxy. This could be all web traffic for data loss prevention, specific categories of websites for compliance, or particular domains that require additional security scrutiny.

The beauty of this approach is that administrators can define these resources using flexible matching criteria including FQDNs, IP subnets, and DNS patterns. You're not limited to static IP addresses - you can specify *.example.com to catch all subdomains or use CIDR notation to capture entire network ranges.

The Configuration Journey - Portal to Endpoint

Once configured in the portal, these resource definitions need to make their way down to the endpoints where the actual steering decisions happen. This process involves several key components and file locations that vary by operating system.

ZTA Enrollment and Configuration Storage

The Zero Trust Access module on each endpoint maintains two critical pieces of information in local JSON files. Understanding where these files live and what they contain is key to troubleshooting and understanding the steering process.

On macOS:

• Enrollment Information: /opt/cisco/secureclient/zta/enrollments/*.json
• Steering Configuration: /opt/cisco/secureclient/zta/enrollments/cached_configs/*.json

On Windows:

• Enrollment Information: C:\ProgramData\Cisco\Cisco Secure Client\ZTA\enrollments\*.json
• Steering Configuration: C:\ProgramData\Cisco\Cisco Secure Client\ZTA\enrollments\cached_configs\*.json

When a device unenrolls from Secure Access, these JSON files are removed, effectively clearing the local steering configuration and returning the endpoint to direct connectivity for all traffic.

Enrollment Information Deep Dive

The enrollment JSON file contains the foundational information that establishes the relationship between the endpoint and the Secure Access cloud. Let's examine what's actually stored in this file:

{
    "org_id": "5555555",
    "duo_device_id": "12348c52f71d4d2d8072cc03dc691234",
    "ztna_device_id": "123400e2f8371234",
    "dha_base_url": "sseposture-routing-commercial.k8s.5c10.org",
    "user_id": "1234118871",
    "label": "SSE enrollment by user Dominic@lookingpoint.com",
    "type": "CiscoSecureAccess",
    "local_uid": "501",
    "enrollment_time": "1757706477",
    "config_sync_url": "https://proxy-8337829.zpc.sse.cisco.com/.well-known/zta-config/cisco/v2",
    "config_etag": "123414fd341deaae29ee0e8a3cf5e4fa",
    "config_hash": "12342885EF0F1041E1F870C713C1047720DAF2AB95E10BDF37FFDFADF045FA03",
    "config_sync_interval": "10",
    "last_config_sync_success_time": "1757709536",
    "last_config_sync_response_time": "1757709536",
    "fail_cnt_since_last_sync_success": "0",
    "choice_id": "cisco-secure-access/default",
    "certificate_expiration_time": "1760729876",
    "certificate_state": "Ok",
    "acme_dir_url": "https://prod.acme.sse.cisco.com/acme/acme/directory"
}

The enrollment file serves as the endpoint's identity document and configuration source. The config_sync_url is particularly important as it defines where the endpoint should fetch its steering configuration updates. The config_sync_interval determines how frequently (in minutes) the endpoint checks for configuration changes.

The Steering Configuration - Where the Magic Happens

The real traffic steering intelligence lives in the cached configuration JSON file. This is where the Private Resources and Internet Resources from the portal get translated into actionable steering rules. Let's break down the structure:

Global Settings and Proxy Configurations

The configuration begins with global settings and proxy definitions:

{
"ztnaConfig":{
    "global_settings":{
        "exclude_local_lan":true
    },
    "proxy_configs":[
        {
        "id":"default_spa_config",
        "label":"Secure Private Access",
        "match_resource_configs":["spa_steering_config"],
        "proxy_server":"spa_proxy_server"
        },
        {
        "id":"default_tia_config",
        "label":"Secure Internet Access",
        "match_resource_configs":["tia_steering_config"],
        "proxy_server":"tia_proxy_server"
        }]
}

The exclude_local_lan setting is worth noting - when set to true, it ensures that local network traffic (think your printer, local file shares, or other devices on the same subnet) doesn't get unnecessarily routed through the cloud proxy.

Each proxy configuration links specific steering rules (match_resource_configs) to proxy servers. This creates the logical connection between "what traffic" (defined in resource configs) and "where to send it" (defined in proxy servers).

Proxy Server Definitions

The proxy servers section defines the actual cloud endpoints that will handle the tunneled traffic:

"proxy_servers":[
    {
    "id":"spa_proxy_server",
    "label":"SPA Proxy Server",
    "url":"proxy-8337829.zpc.sse.cisco.com"
    },
    {
    "doh_url":"https://proxy-8337829.tia.sse.cisco.com/dns-query",
    "id":"tia_proxy_server",
    "label":"TIA Proxy Server",
    "url":"proxy-8337829.tia.sse.cisco.com"
    }]

Notice that the TIA proxy server includes a doh_url (DNS over HTTPS) configuration. This enables secure DNS resolution through the cloud proxy, ensuring that even DNS queries for internet resources are processed securely.

Resource Configurations - The Steering Rules

Here's where the Private Resources and Internet Resources from the portal are translated into concrete steering logic:

SPA Steering Configuration:

{
"cidr":
    {   
    "include":["10.99.99.10/32","10.99.99.254/32"]  
    },
"fqdn":
    {
    "exclude":["*.sse.cisco.com"],
    "include":["ise.example.com","ise01.example.com","ise02.example.com","*.zpc.sse.cisco.test"]
    },
"id":"spa_steering_config",
"label":"SPA Steering Config"
}

The SPA configuration defines your private resources using both CIDR blocks and FQDN patterns. The include lists specify traffic that should be routed through the SPA proxy, while exclude lists create exceptions. In this example, specific ISE servers and internal IP addresses will be routed through SPA, but the Secure Access infrastructure itself (*.sse.cisco.com) is excluded to prevent recursive tunneling.

SIA Steering Configuration:

{
"cidr":
    {
    "exclude":["10.0.0.0/8","172.16.0.0/12","192.168.0.0/16"],
    "include":["0.0.0.0/0"]},
    "dns":
        {
        "exclude":["*.local","amp.cisco.com","azure.com","cisco.com","sslvpn-colo.personalis.com","*.sse.cisco.com","*.umbrella.com","*.opendns.com"],
        "include":["*"]
        },
    "id":"tia_steering_config",
    "label":"TIA Steering Config"
}

The SIA configuration takes a different approach - it includes all internet traffic (0.0.0.0/0) but excludes private IP ranges and specific domains that should remain local or direct. The DNS section provides additional granular control over DNS-based steering decisions.

Socket-Level Traffic Interception

Now that we understand how the steering configuration gets to the endpoint, let's examine how traffic actually gets intercepted and routed. The Zero Trust Access module operates at the socket level, intercepting connection attempts before they leave the endpoint.

When an application attempts to establish a network connection, the ZTA module evaluates the destination against its cached steering configuration. This evaluation happens in real-time and follows a specific decision tree:

1. Destination Analysis: The module examines the destination IP, FQDN, or DNS query against the resource configurations
2. Rule Matching: It determines which proxy configuration (SPA, SIA, or none) applies based on the include/exclude rules
3. Proxy Selection: If a match is found, the connection is redirected to the appropriate proxy server
4. Certificate Validation: The module uses its enrolled certificate to establish a secure tunnel to the proxy
5. Traffic Forwarding: The original application traffic is forwarded through the established tunnel

This process is transparent to the application - from the application's perspective, it's making a normal network connection. The ZTA module handles all the complexity of determining routing and establishing secure tunnels.

Configuration Synchronization

The endpoint doesn't just grab its configuration once and forget about it. The config_sync_url and config_sync_interval ensure that steering configurations stay current with changes made in the portal. Every few minutes (based on the sync interval), the endpoint checks for configuration updates using ETags to determine if anything has changed.

This synchronization mechanism ensures that when administrators add new private resources or modify internet access policies in the portal, those changes propagate to endpoints relatively quickly without requiring manual intervention or client restarts.

Troubleshooting and Verification

Understanding these file locations and configuration structures becomes invaluable when troubleshooting Zero Trust client behavior. If users are reporting that internal applications aren't accessible or that internet traffic isn't being properly filtered, examining these JSON files can quickly reveal misconfigurations or synchronization issues.

You can verify enrollment status by checking for the presence of the enrollment JSON file and examining its certificate state and sync timestamps. Configuration issues often surface in the cached_configs JSON where you can validate that the expected steering rules are present and properly formatted.

What's Next?

We've peeled back the layers to reveal how Cisco Secure Access orchestrates zero trust client traffic steering from portal configuration all the way down to socket-level interception. The elegant integration between centralized policy management and distributed enforcement enables organizations to implement comprehensive zero trust network access without sacrificing user experience or administrative control.

In future entries, we might explore advanced steering scenarios, certificate management in ZTNA deployments, or integration patterns with other security tools. What would you like to see covered next? Drop a comment and let me know what aspects of zero trust networking you'd like to dive deeper into!

Thanks for reading, and remember - in zero trust, never trust, always verify... even your traffic steering configurations! Let us know if you have any questions about your security infrastructure at sales@lookingpoint.com.