Microsoft Global Secure Access – Incorrect egress geolocation for users physically located in Spain

Global Secure Access cannot guarantee Spanish egress or force users onto the Madrid PoP; for affected third-party sites, the supported choices are to route those applications through a Spanish network by using Source IP anchoring or bypass their traffic so it exits through the user’s local connection.

Expected behavior and PoP selection

Global Secure Access uses Anycast and dynamically selects an available Microsoft PoP. Microsoft does not provide dedicated or static public IP addresses for individual data centers, regions, or physical locations, even though Madrid is an active Global Secure Access location. Dublin, Marseille, and Paris are also active European locations.^1^

Consequently:

• Windows location, language, time zone, and GeoId do not select the PoP.
• Changing the local ISP does not necessarily change the selected Microsoft edge.
• There is no tenant setting to force Madrid, block French/Irish PoPs, or guarantee that generic Internet traffic presents a Spanish public IP. A closely matching GSA case confirms that country-specific PoP enforcement is not currently configurable.^2^
• A destination website sees the GSA edge address rather than the device’s original address, which Microsoft documents as a limitation affecting geolocation-dependent services.^3^

Supported tenant-level alternatives

1. Source IP anchoring for selected SaaS or web applications

Where a site must always see a Spanish address, Source IP anchoring can route its traffic through a private network connector in a network whose controlled egress IP is Spanish. The destination then sees that fixed organizational egress address.^4^

Prerequisites include Microsoft Entra Suite or Entra Private Access, an enabled Private Access profile, a current GSA client, and a private network with outbound connectivity to the application.

High-level configuration:

1. Deploy at least two Private Network Connectors in a Spanish private network or Azure virtual network with a controlled Spanish egress IP.
2. In the Microsoft Entra admin center, go to Global Secure Access → Applications → Enterprise applications → New application.
3. Select the connector group.
4. Add an application segment:
   • Destination type: Fully qualified domain name
   • FQDN: affected website
   • Ports: 80, 443, or both
   • Protocol: TCP
5. Assign the relevant users or groups.
6. In the Windows GSA client, open Advanced Diagnostics → Traffic, reproduce the request, and verify:
   • Channel: Private Access
   • Action: Tunnel
7. Check the destination application’s logs and confirm it sees the Spanish network’s egress IP.

This avoids direct Internet bypass, but it remains destination-specific; the documented feature does not provide one Spanish egress address for all Internet Access traffic.

2. Bypass affected destinations

If anchoring is not appropriate, configure the affected FQDNs or IPs with Action: Bypass in the applicable forwarding policy. Bypassed traffic skips GSA acquisition and uses the client’s normal local Internet path.^5^

This is the practical fallback for sites that rely on consumer geolocation, but bypassed traffic does not receive GSA inspection and controls.

3. Source IP restoration—Microsoft services only

For incorrect location in Microsoft Entra ID or Microsoft Graph rather than third-party websites, enable:

Global Secure Access → Settings → Session management → Adaptive Access → Enable Conditional Access Signaling for Microsoft Entra ID

Source IP restoration communicates the user’s original public egress IP to Entra ID and Microsoft Graph, improving Conditional Access, risk detection, and sign-in log accuracy. It does not change the address seen by arbitrary Internet websites.^6^

Microsoft Support review

Support can investigate an unexpected edge assignment or incorrect Microsoft-side IP classification, but that review does not create a country-pinning guarantee.

Capture evidence during an affected session:

1. Open the GSA tray icon → Advanced Diagnostics → Advanced log collection.
2. Select Start recording, reproduce the affected website request, then select Stop recording.
3. Retain the generated ZIP and ETL files from C:\Program Files\Global Secure Access Client\Logs.^7^
4. Include in the support request:
   • UTC timestamp and user’s physical location
   • GSA client version
   • Destination FQDN
   • Public egress IP observed by the destination
   • PoP/connection details shown by Advanced Diagnostics
   • Whether Entra sign-in logs or only third-party websites show the wrong country
   • Examples of geolocation providers returning France or Ireland
   • The collected diagnostics ZIP

The classification could be caused by a destination’s Geo-IP database, but routing to a French or Irish edge is also valid GSA behavior. Compare several affected sites against the exact observed egress IP before requesting an IP-classification review; Microsoft publishes shared GSA egress ranges rather than country-specific ranges.^8^

References

1. Global Secure Access points of presence and IP addresses
2. Can you force GSA to use a POP within a country? - Microsoft Q&A
3. Known limitations for Global Secure Access
4. Source IP anchoring with Global Secure Access
5. How to enable and manage the Microsoft traffic forwarding profile
6. Tutorial: Enable source IP restoration - Global Secure Access
7. Troubleshoot the Global Secure Access client for Windows: Advanced diagnostics
8. Global Secure Access egress IP ranges