Some websites and applications restrict access to users connecting from specific countries or a limited set of IP addresses. Geo-anchoring lets you route traffic through a Netskope data plane in an approved region, so your users can reach these sites without losing Netskope’s security inspection.
This topic explains when to use geo-anchoring and how to configure it for tenants with and without Dedicated Egress IPs (DEIP).
When to use geo-anchoring
Use geo-anchoring when your users hit one of these problems:
- A site blocks your region. The destination site only allows traffic from specific countries, and your users connect through a Netskope data plane outside that list. For example, your US-based users need to reach a site that only accepts traffic from India.
- A site accepts only a limited number of source IPs. If you use DEIP, your tenant’s full IP range can be too large for some destination applications to allow-list. Geo-anchoring lets you narrow the source IPs the destination sees.
- A site serves region-specific content. Some sites detect the visitor’s location from the connecting IP address and serve region-specific content — local language, pricing, or catalogs — based on that point of presence (POP). Geo-anchoring routes the request through a data plane in the target region, so users see the same regional experience as a local visitor.
Geo-anchoring adds latency, because traffic now travels to a second, more distant data plane before reaching its destination. The extra delay scales with the distance between your users’ data plane and the egress data plane you choose. Route only the traffic that needs it, and let everything else take the direct path.
Geo-anchoring uses the Forward to Proxy action, which doesn’t support HTTP/2. You must disable HTTP/2 on your tenant.
How it works
Geo-anchoring uses the Forward to Proxy action to send matching traffic to a second Netskope data plane in your chosen region. That data plane then forwards the request to the destination site, which sees the second data plane’s IP address as the source.
Two deployment models are available, depending on whether your tenant uses DEIP:
| Model | How it works | Requirements |
|---|---|---|
| Without DEIP | Your tenant forwards traffic to a shared geo-anchoring tenant that Netskope manages. | SSL decryption must be enabled — Do Not Decrypt traffic isn’t supported. Your tenant must trust the geo-anchoring SSL certificate. |
| With DEIP | Your own tenant processes the request a second time in the target region, so no shared tenant or certificate exchange is needed. | You must configure anti-loop policies so the second pass doesn’t re-trigger the same forwarding rule. |
Set up geo-anchoring without DEIP
Step 1: Trust the geo-anchoring certificate
- Go to Settings > Manage > Certificates > Trusted CA > New Trusted CA.
- Add the geo-anchoring Root CA certificate.
- Click Validate, then Save.
Step 2: Create the proxy
- Go to Settings > Manage > Forward to Proxy Integration > Setup Proxy.
- Enter the region’s FQDN and port (see the region tables below).
- Select X-Forwarded-For and Tenant-Info. Requests that arrive without these headers will be rejected.
- Save the proxy.
Step 3: Define the traffic to forward
- Go to Policies > Web > URL List > New URL List and add the hosts or URLs that need geo-anchoring.
- Go to Policies > Web > Custom Categories > New Custom Category and add the URL list to a category.
- Go to Policies > Real-time Protection > New Policy > Web Access, match the custom category, and set the action to Forward to Proxy, pointing to the proxy you created in Step 2.
- Save and apply the policy.
Tip: If the sites you need to geo-anchor already fall under one of Netskope’s predefined categories, you can match that category directly in your Real-time Protection policy and skip the URL list and custom category steps above.
Step 4: Test it
Browse to a site like ifconfig.me through a rule that matches your geo-anchoring policy, and confirm the reported egress location matches your chosen region.
Set up geo-anchoring with DEIP
With DEIP, your own tenant handles the request twice — once at the initial data plane and again at the target region — so you don’t need to exchange certificates with a shared tenant. Because the same tenant processes the request twice, you must configure anti-loop protection, or traffic will loop and the destination site will become unreachable.
Dedicated FQDNs are required for DEIP deployments. Request yours through your Netskope contact (CSM, TAM, SE, or SA) — don’t reuse the shared-IP region FQDNs, since they may not remain reliable as new data planes come online.
Step 1: Identify your DEIP source IPs
Go to Settings > Secure Cloud Platform > Reverse Proxy > SAML > Netskope Source IP and use Copy IP Ranges to get your dedicated IP list.
Step 2: Create a network location for your DEIPs
- Paste your IP list into a spreadsheet, one IP per cell, with the network object’s name in the first cell.
- Save it as a CSV.
- Go to Policies > Profiles > Network Location > New Network Location > Multiple Objects and import the file.
Step 3: Add an authentication bypass
Go to Settings > Security Cloud Platform > Forward Proxy > SAML > Settings > Bypass, and enter your new network location under Egress IP Address Bypass.
Step 4: Prevent double decryption (recommended)
- Go to Policies > SSL Decryption > Add Policy.
- Create a policy at the top of the list that matches Source IP (Egress) against your DEIP network location, with the action Do Not Decrypt.
- Enable and save the policy.
This step requires the Forward to Proxy for SSL Bypassed Traffic tenant flag, since the second pass now carries non-decrypted traffic.
Step 5: Add an anti-loop policy
Go to Policies > Real-time Protection > Add Policy and add a policy in the header section, above any Allow policy, that excludes your DEIP network location from the forwarding rule. Without this, the second pass will re-match the same Forward to Proxy policy and loop indefinitely.
Step 6: Allow-list your source IPs
Go to Settings > Security Cloud Platform > Traffic Steering > Explicit Proxy > IP Address Allowlist & User Identity, and add your DEIP list as comma-separated values.
Step 7: Create the proxy
Go to Settings > Manage > Forward to Proxy Integration > Setup Proxy and add your dedicated region FQDN (requested in the introduction above). Do not use a shared-IP region here.
Step 8: Define the traffic to forward
Follow the same URL list, custom category, and Real-time Protection policy steps described in Step 3 of the non-DEIP setup, pointing to the proxy from Step 7. Confirm your anti-loop policy (Step 5) is active before you apply this policy.
Step 9: Test it
Browse to a site like ifconfig.me and confirm the egress location matches your chosen region.
Alternative: keep SSL decryption on the second pass
If you’d rather not configure Do Not Decrypt (Step 4), you can keep SSL decryption active on the second pass instead. Download your Netskope Root Certificate (or your BYOK CA, if applicable) from Settings > Manage > Certificates > Signing CA, then add it under Settings > Manage > Certificates > Trusted CA > New Trusted CA, validate, and save.
Verify your configuration
- Page Events show the forwarded proxy name under Forward Proxy Profile.
- Transaction Events confirm forwarding: Format 3 includes x-policy-action=forward and x-policy-name; Format 4 includes x-sr-forward-dest with the destination proxy name (empty if the request wasn’t forwarded). DEIP configurations generate two transaction events — one per data plane pass.
- Visiting a diagnostic site such as ifconfig.me through a matching rule confirms the egress region.
Supported regions (shared IP)
Fully redundant regions (multiple data planes)
| FQDN | Region Code | Region |
|---|---|---|
| geoanchoring-ae.goskope.com | ae | United Arab Emirates |
| geoanchoring-au.goskope.com | au | Australia |
| geoanchoring-br.goskope.com | br | Brazil |
| geoanchoring-ca.goskope.com | ca | Canada |
| geoanchoring-ch.goskope.com | ch | Switzerland |
| geoanchoring-co.goskope.com | co | Colombia |
| geoanchoring-de.goskope.com | de | Germany |
| geoanchoring-es.goskope.com | es | Spain |
| geoanchoring-fr.goskope.com | fr | France |
| geoanchoring-gb.goskope.com | gb | United Kingdom |
| geoanchoring-in.goskope.com | in | India |
| geoanchoring-it.goskope.com | it | Italy |
| geoanchoring-jp.goskope.com | jp | Japan |
| geoanchoring-sa.goskope.com | sa | Saudi Arabia |
| geoanchoring-us.goskope.com | us | United States |
| geoanchoring-za.goskope.com | za | South Africa |
Single-data-plane regions (backed up from a nearby country)
If the data plane for one of these countries is unavailable (for example, during scheduled maintenance), traffic fails over to another country. Sites that enforce source-country restrictions may be temporarily unreachable during that window.
| FDQN | Region Code | Region |
|---|---|---|
| geoanchoring-ar.goskope.com | ar | Argentina |
| geoanchoring-at.goskope.com | at | Austria |
| geoanchoring-be.goskope.com | be | Belgium |
| geoanchoring-cl.goskope.com | cl | Chile |
| geoanchoring-cz.goskope.com | cz | Czech Republic |
| geoanchoring-fi.goskope.com | fi | Finland |
| geoanchoring-ie.goskope.com | ie | Ireland |
| geoanchoring-il.goskope.com | il | Israel |
| geoanchoring-kr.goskope.com | kr | South Korea |
| geoanchoring-mx.goskope.com | mx | Mexico |
| geoanchoring-ng.goskope.com | ng | Nigeria |
| geoanchoring-nl.goskope.com | nl | Netherlands |
| geoanchoring-nz.goskope.com | nz | New Zealand |
| geoanchoring-pe.goskope.com | pe | Peru |
| geoanchoring-ph.goskope.com | ph | Philippines |
| geoanchoring-pl.goskope.com | pl | Poland |
| geoanchoring-pt.goskope.com | pt | Portugal |
| geoanchoring-sg.goskope.com | sg | Singapore |
| geoanchoring-th.goskope.com | th | Thailand |
| geoanchoring-tw.goskope.com | tw | Taiwan |
Limitations
- Because geo-anchoring is based on the Forward to Proxy action, which doesn’t support HTTP/2, you must disable HTTP/2 on your tenant.
- The Forward to Proxy action does not support instance-based policies.
- Without DEIP, SSL decryption is mandatory in the geo-anchoring tenant — Do Not Decrypt traffic is not supported there.
- Route only the traffic that needs geo-anchoring. Every forwarded request adds latency, and user experience degrades with distance between the two data planes.