Cisco Secure Access Help

PDF

Cisco Secure Access Help

Endpoint Data Center Selection

Updated: August 24, 2026

Want to summarize with AI?

Log in

Explans how DNS, Geo-Load Balancing (GeoLB), Anycast, routing policies, and configuration choices influence the data center where your users connect.

As organizations deploy Cisco Secure Access, a common question arises: “How does the endpoint decide which data center to connect to?”

Cisco Secure Access does not have a single "nearest data center" rule that governs all traffic. Cisco Secure Access utilizes distinct architectural paths depending on the service being consumed - Secure Client roaming web protection (SWG), Zero Trust Access (ZTA) for private applications, Trusted Internet Access (TIA), or Remote Access VPN (VPNaaS).

This section bridges the gap between high-level summaries and deep-dive architectural behavior, explaining how DNS, Geo-Load Balancing (GeoLB), Anycast, routing policies, and configuration choices influence where your users connect.

Roaming Web Protection (Secure Web Gateway)

When the Secure Client provides roaming web protection using the Secure Web Gateway (SWG) module, it connects the user to Cisco's cloud web-security service.

Discovery and Initial Placement

The client relies on DNS-based service discovery. It queries either a standard Cisco proxy hostname (e.g., swg-url-proxy-https-sse.sigproxy.qq…) or a newer version with the customers’ org ID embedded (e.g., swg-url-proxy-https-\#\#\#\#\#.sseproxy.qq…), and the DNS resolver returns the IP address of the closest optimal data center. Anycast routing ensures the endpoint reaches a nearby DNS resolver, optimizing the initial connection speed.

Geo-Load Balancing (GeoLB) and Country Rules

Proximity is the baseline, but GeoLB can override the "closest" data center. GeoLB is the intelligent global load balancer that incorporates customer preferences, reserved IP configurations, country alignment, and more.

It uses the public IP of the client (embedded in EDNS Client Subnet data) as well as the org ID (implicitly looked up via network registration, or gathered explicitly if embedded in the FQDN). For geolocation, a dynamic lookup is performed against IP-to-location services to detect the source country of the user.

You can ues GeoLB to apply the following:

  • Maintenance & Failover: Seamlessly shifting traffic away from data centers undergoing maintenance.

  • Regional Balancing: Distributing load across multiple facilities.

  • Country Ring-fencing: Keeping user traffic within national borders or preferred neighboring countries where possible.

Note
This is a best-effort feature, and subject to the accuracy of the geolocation of the public IP of the client.

Reserved IP and Ingress Control

If your organization purchased Reserved IP to ensure dedicated egress IP addresses for SaaS allowlisting, the data center selection logic changes significantly.

  • Ingress Control: Cisco must ensure the user connects to a data center where your organization actually holds a reserved IP.

  • If the physically closest data center does not have your reserved IP provisioned, the network will automatically bypass it and route the user to the nearest data center that does host your reserved IP.

Note
Reserved IP ingress control is primarily supported for standard HTTP/HTTPS roaming SWG traffic.

Zero Trust Access (ZTA) for Private Applications

Client-based ZTA intercepts traffic destined for configured private resources and brokers the connection through the Secure Access cloud without requiring a traditional VPN tunnel.

Note
Because ZTA always ingresses to the nearest PoP, a user traveling in Canada will ingress into a Canadian data center. If your application requires a US source IP, you do not force the user's ingress to the US. Instead, you deploy the Resource Connector in a US-based environment (e.g., AWS US-East). The traffic will automatically backhaul across the Cisco backbone and egress out of the US-based Resource Connector, satisfying the geo-blocking requirement.

Ingress and Traffic Pathing

The ZTA client has slightly different data center selection logic than the SWG module. The design minimizes the first-mile and last-mile time spent on the internet, and maximizes connection time spent on the Cisco backbone.

  • Ingress: The ZTA client utilizes DNS proximity routing to connect to the nearest available ZTA Point of Presence (PoP).

  • Backbone Transport: Once connected, the traffic traverses the Cisco Secure Access backbone.

  • Egress: The traffic routes to the Cisco PoP closest to where your Resource Connector or IPsec tunnel is deployed.

  • Delivery: The Resource Connector delivers the traffic to the private application.

Universal / Hybrid ZTNA and Trusted Networks

If your environment utilizes Universal /Hybrid ZTNA with Cisco Secure Firewalls, the ZTA client performs Trusted Network Detection (TND). If the client determines it is on a trusted internal corporate network, Secure Access redirects the connection to a local on-premises Secure Firewall enforcement point, entirely bypassing the cloud PoP to prevent unnecessary hairpinning.

Failover

ZTA session failover is evaluated per private resource attempt. If an active PoP goes offline, the client uses DNS to seamlessly resolve and connect to the next closest available data center. This happens transparently to the user without dropping the overall Secure Access application session.

Trusted Internet Access (TIA) via the ZTA Client

Trusted Internet Access leverages the modern ZTA client architecture to secure outbound internet destinations, applying device posture checks, firewall rules, IDS/IPS, and SWG enforcement.

  • Placement: The TIA client connects to the nearest available cloud enforcement PoP that your organization has explicitly enabled. Only data centers that the customer has requested to be enabled (via TAC/Support) are considered for connection. If a specific PoP is not enabled for your tenant, users will never connect to it, regardless of proximity.

  • Best Practice for Availability: Customers should always have at least two DCs or Regions enabled to ensure proper high availability and failover routing.

  • Distinction from SWG roaming module: TIA utilizes a newer version of the global DNS balancer. It has similar latency-based selection of the nearest enabled data center for the client requests.

  • Failover: TIA relies on the inherent multi-region resiliency of the ZTA architecture. If a local region is degraded, traffic is seamlessly handled by neighboring enabled regions.

Remote Access VPN (VPNaaS)

Secure Access provides Remote Access VPN using a unique organizational FQDN (e.g., your-org-id.vpn.sse.cisco.com).

Default Data Center Selection

By default, when a user initiates a VPN connection to your organizational FQDN, Cisco's DNS routing dynamically directs them to the closest available PoP or Region. The user is locked to that data center for the duration of the session.

Administrator Controls and Regional Profiles

While auto-selection based on proximity is the default, administrators have significantly more control over VPN placement than they do with ZTA ingress:

  • Region-Specific Profiles: Administrators can push region-specific VPN profiles and FQDNs to Secure Clients. This allows end-users to manually select their connection region via a drop-down (e.g., forcing a connection to a European hub while traveling in the US).

  • IP Pools: Administrators must configure IP pools (up to 50 per region). Users can only connect to regions where an admin has actively deployed VPNaaS and allocated IP pools.

High Availability and Failover

VPN failover is aggregated for all private resources in a session.

  • Within a region, VPNaaS is distributed across multiple Availability Zones (AZs) or Virtual Edge Data Centers (VEDCs). If one fails, users are automatically handled by the other AZ.

  • If an entire region fails, users can automatically fail over to a secondary region—provided the administrator has configured IP pools in that secondary region.

Regional and US Federal Government Deployments

Depending on regulatory and compliance requirements, Secure Access offers specialized environments with strict rules on data center selection and client roaming:

  • Secure Access China (SSE China): For organizations utilizing Secure Access China, Roaming Client traffic features automatic geographical detection. The client detects whether the user is inside or outside of China and seamlessly adjusts the set of data centers it connects to.

    Note

    A customer must have subscriptions to both global Secure Access and Secure Access China for this seamless internal/external roaming to function

  • Secure Access - Local data residency deployments: With these deployments, data in the control, management, and data planes remains in a specific region rather than using a global cloud. The features are comparable to standard Secure Access.

  • Cisco Secure Access for Government: This is a separate instance of Secure Access certified for FedRAMP Class D (High). Access to this product is restricted to eligible users under FedRAMP PMO and CISA regulations. Government users must connect within the government boundary at the government cloud access points.

Information to Gather Before Contacting Cisco Support

If you suspect users are terminating in the incorrect region or experiencing sub-optimal routing, gather the following before opening a case:

  • Connection Method: Is the user connecting via SWG Roaming Module, ZTA Private Access, TIA, or RA VPN?

  • Network State: Is the device on a trusted corporate network or a remote/public network?

  • DNS Resolution: What IP address does the client resolve for the Secure Access proxy or VPN headend? (Are they using public DNS, ISP DNS, or Cisco Umbrella resolvers?)

  • Enabled PoPs (for TIA): Have you verified with TAC which data centers are actively enabled for your organization's TIA routing?

  • Reserved IP: Does your organization utilize Reserved IP, and is the provisioned region different from the user's physical location?

  • Application Architecture: If complaining about "wrong location" for private apps, where is the Resource Connector deployed?

  • VPN Config: For VPN, which profile is the user selecting, and are IP pools configured in the expected region?

  • Tenant Type: Is the user registered to a specialized environment (such as Secure Access China, Cisco Secure Access for Government, or a local data residency) that enforces strict boundary rules?