[FEATURE] Recognise Microsoft Global Secure Access synthetic IPs (`6.6.0.0/16`) for gateway `/login`

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

/login for an apps gateway rejects the connection unless the gateway hostname resolves to a private IP:

Error: Gateway hosts must be on your organization's private network;
gateway.internal.example resolves to the public (or unrecognized) address
6.6.1.243. Connect to your organization's network (or VPN) and try again.

Organisations using Microsoft Entra Global Secure Access (GSA) Private Access — a Zero Trust Network Access product, and a common VPN replacement — cannot reach a gateway this way, even though the traffic never leaves the corporate tunnel.

GSA does not hand the application the resource's real RFC 1918 address. By design it returns a synthetic IP from 6.6.0.0/16 and uses it to steer the connection through the GSA tunnel. This is documented behaviour, not a misconfiguration:

"DNS proxy responds back to the client with the internal IP. The client stores the internal IP address and returns a synthetic IP to the application." — Microsoft Learn: Understand Microsoft Entra Private DNS

The 6.6.0.0/16 synthetic range is returned for both FQDN-based application segments and the newer Private DNS feature, so there is no GSA-side configuration that makes the resource resolve to a real 10.x/172.16.x/192.168.x address on the client. The application always sees 6.6.x.x.

6.6.0.0/16 is a publicly-allocated IANA block, so Claude Code correctly classifies it as non-private and refuses. The result is that an entire class of Zero Trust customer cannot use the gateway at all, despite the connection being strictly internal to the GSA overlay.

Proposed Solution

Treat the GSA synthetic range 6.6.0.0/16 as an internal range for the gateway host check — the same way 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 are already accepted.

6.6.0.0/16 is Microsoft's fixed, well-known synthetic range for GSA Private Access. It is non-routable on the public internet and is only meaningful on a device enrolled in that tenant's GSA client — a connection to a 6.6.x.x address cannot leave the machine except through the GSA tunnel. Recognising this specific, bounded range does not expose the machine to an arbitrary attacker-controlled public host.

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

Using Entra Global Secure Access as a VPN replacement and route internal apps through Private Access application segments. Give developers managed, cost-controlled access to Bedrock/Vertex/etc. through the apps gateway, authenticated by corporate SSO. The gateway ALB is internal and only reachable over the GSA tunnel — but because GSA presents it to the client as 6.6.x.x, /login refuses to connect, and there is no GSA setting that changes what IP the application sees.

Additional Context

• Repro: publish the gateway FQDN as a GSA Private Access application segment (or via Private DNS), then claude /login against it from a GSA-enrolled machine. The resolved address will be in 6.6.0.0/16.
• The synthetic-IP mechanism is inherent to GSA Private Access and affects any application that needs the resource's real address; Microsoft documents the same class of breakage for Kerberos SPNs on the page linked above.
• Recognising known, internet-non-routable synthetic/CGNAT-style ranges this way could also cover other SSE/ZTNA vendors that present resources through similar fixed ranges — each added as a specific, bounded range rather than an open allowlist.