Sign in errors, private ipv6, and Global Secure Access

Question

Sign in errors, private ipv6, and Global Secure Access

Neil Beytagh 11

All of our users have Global Secure Access deployed and Entra Internet profile deployed. That profile tunnels all internet traffic through GSA.

Recently, we've had some issues with a handful of our users signins violating a conditional Access Policy that dictates that they can only sign in from known and allowed geographic locations. For some reason, the reported IP for some of the signins pulls in as a PRIVATE ipv6 address, which reports no location, thus failing on the Location CAP.

We have run the registry fix for all endpoints to set ipv4 preferred, as well as going all the way to disabling ipv6 on the network adapter itself. Our workaround is to enforce a100% compliant device CAP and opt them out of the location policy.

I am not aware if we have disabled DNS over https yet, but would love some more insight as to what is going on.

Praveen Chivarla 2,005 Reputation points Microsoft External Staff Moderator

2025-09-08T08:01:40.2366667+00:00

Hi @Neil Beytagh,

Following up to see if the above answer was helpful. If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know
Praveen Chivarla 2,005 Reputation points Microsoft External Staff Moderator

2025-09-09T09:18:26.0133333+00:00

Hi @Neil Beytagh,

Following up to see if the above answer was helpful. If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know

1 answer

Your answer

Praveen Chivarla 2,005 Reputation points Microsoft External Staff Moderator

2025-09-08T08:01:40.2366667+00:00

Hi @Neil Beytagh,

Following up to see if the above answer was helpful. If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know
Praveen Chivarla 2,005 Reputation points Microsoft External Staff Moderator

2025-09-09T09:18:26.0133333+00:00

Hi @Neil Beytagh,

Following up to see if the above answer was helpful. If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know

Answer 1

Hi @Neil Beytagh,

Thank you for posting your query on Microsoft Q&A.

As per our understanding, your users are experiencing conditional access policy failures in Microsoft Entra due to private IPv6 addresses being reported during sign-ins while using Global Secure Access (GSA) and the Entra Internet profile. Your intent was to enforce access based on geographic location, but the sign-in process is instead seeing private IPv6 addresses, which have no public geolocation data, causing location-based Conditional Access (CAP) to block these sessions. Despite attempts to prefer or disable IPv6 and some workarounds, the problem persists.

Global Secure Access tunnels traffic through virtual network interfaces, often assigning a private (non-routable) IPv6 address on the client.
Microsoft Entra Conditional Access location-based policies require a public IP address to identify location; private IPs (including those starting with fe80::/64) cannot be mapped to a location and thus fail the policy.
Disabling IPv6 at the network adapter may not affect the GSA virtual adapter, so the problem persists after endpoint-level changes.

Please follow the steps below to solve the issue:

Define your GSA Egress IP Ranges as Named Locations:
- In the Entra admin center, go to Identity > Conditional Access > Named locations.
  - Click New location and enter the public IP address ranges (IPv4/IPv6) your GSA service uses to egress to the internet. Mark these as "trusted location". You may need to coordinate with your network or security team to confirm these addresses.
  1. Update your Conditional Access Policy:
    - Go to your location-based policy and, under Locations, include your new GSA egress “named location” entries in the Allow list or exclude them from the conditional check to permit sign-ins from these ranges.
    1. Check IPv6 Settings on GSA Adapter:
      - Disabling IPv6 on the primary network adapter may not affect the GSA virtual interface. For advanced cases, use PowerShell to list and adjust the adapter bindings specifically for the GSA network adapter.
      1. DNS Settings:
        
        DNS over HTTPS support is limited in Global Secure Access. If you suspect name resolution or traffic routing issues, disable secure DNS in your endpoints’ browser and device settings, per your organization’s policy.
        
        Require Device Compliance Only
        
        As a secure workaround, enforce access using a device compliance policy in Conditional Access, rather than using location. This ensures only managed, compliant devices can access resources, even if their IP address is private/unmappable by location.

Please refer to: https://v4.hkg1.meaqua.org/en-us/entra/global-secure-access/resource-faq

https://v4.hkg1.meaqua.org/en-us/entra/global-secure-access/how-to-compliant-network

https://v4.hkg1.meaqua.org/en-us/entra/identity/conditional-access/policy-block-by-location

https://v4.hkg1.meaqua.org/en-us/entra/identity/conditional-access/concept-assignment-network

Please "Accept as Answer" if the answer provided is useful, so that you can help others in the community looking for remediation for similar issues.

Share via

Sign in errors, private ipv6, and Global Secure Access

1 answer

Your answer