Giving SaaS Applications a Fixed Egress IP with Microsoft Entra Private Access

Microsoft Entra Global Secure Access changes how we think about the corporate network perimeter. Instead of trusting users because they are connected to an office network or a traditional VPN, access can follow the identity and device through Microsoft’s Security Service Edge.

That is a much better model, but it can expose an awkward compatibility problem.

Some Software-as-a-Service platforms still use IP allowlisting as part of their access controls. The application might only accept connections from an organisation’s office, datacentre or another known public IP address. This is particularly common with older SaaS platforms, administration portals and services that don’t integrate cleanly with an identity provider.

Sending the application through Microsoft Entra Internet Access might appear to solve the problem. However, the published Global Secure Access egress ranges are much broader than many services are willing to accept.

The solution is to use Microsoft Entra Private Access to route only that application’s traffic through a network egress address that you control. Microsoft calls this pattern source IP anchoring.

The problem with the Global Secure Access egress ranges

At the time of writing, Microsoft publishes the following egress ranges for internet traffic acquired by Global Secure Access:

  • 128.94.0.0/19
  • 151.206.0.0/16

That represents 8,192 addresses in the /19 and 65,536 addresses in the /16. These are Global Secure Access service ranges; they are not a small, tenant-dedicated set of public addresses.

Microsoft also states that Global Secure Access does not provide dedicated or static public IP addresses for individual datacentres or geographic locations. Its Anycast architecture dynamically routes traffic through the available Microsoft points of presence.

For most internet destinations, none of that is a problem. For a SaaS platform expecting a single office IP address, however, asking the provider to allow tens of thousands of addresses is unlikely to be acceptable. Some platforms limit the number of addresses that can be entered, while others will reject prefixes as broad as /16 or /19 entirely.

The current addresses and Microsoft guidance are available in Global Secure Access points of presence and IP addresses.

IP allowlisting is more accurately described as an IP-based access control than IP authentication. An address can help establish where a connection came from, but it does not prove who is using it. The application should still authenticate and authorise the user properly.

Source IP anchoring

Microsoft Entra Private Access is normally associated with private resources: internal web applications, servers, Remote Desktop, SSH and other services that aren’t directly exposed to the internet.

However, Private Access can also acquire traffic for a public FQDN and send it through a Microsoft Entra private network connector. The connector’s network then establishes the outbound connection to the public application.

The destination application does not see the user’s home IP address or one of the broad Global Secure Access egress ranges. It sees the public egress address of the network containing the connector.

This is the traffic flow:

flowchart LR
    A["Managed endpoint"] --> B["Global Secure Access client"]
    B --> C["Microsoft Security Service Edge"]
    C --> D["Private Access application"]
    D --> E["Private network connector group"]
    E --> F["Controlled public egress IP"]
    F --> G["IP-restricted SaaS application"]

Microsoft documents the pattern in Source IP anchoring with Global Secure Access. The useful part is that Private Access provides more than a network route. Access to the route can be assigned to specific users and groups and protected with Conditional Access.

Source IP anchoring is not source IP restoration

The two similarly named features are easy to confuse:

FeaturePurpose
Source IP anchoringRoutes selected application traffic through a private network so that the destination sees a controlled egress IP address.
Source IP restorationPreserves the user’s original public IP address in supported Microsoft Entra sign-in logs when traffic passes through Global Secure Access.

For an external SaaS application that requires an allowlisted source address, source IP anchoring is the relevant feature.

Can I use my existing connectors?

Possibly. There is no requirement to deploy a new connector group solely for source IP anchoring.

An existing connector group can be used when:

  • Its network has a stable public egress IP address.
  • The network permits outbound access to the SaaS application.
  • The connectors have sufficient capacity for the additional traffic.
  • Sharing the connector group fits the organisation’s security and operational boundaries.
  • The application owner is willing to allowlist that network’s existing public IP address.

This could be a sensible approach when an organisation already has a resilient connector deployment in a datacentre with a well-managed internet connection.

There are also reasons to create a dedicated connector group. It separates the SaaS dependency from connectors serving private applications, provides a cleaner change boundary and makes the source IP easier to control. It also avoids hairpinning traffic through an office or datacentre simply because that is where the existing connectors happen to live.

For a new deployment, my preferred design is a dedicated connector group in Azure with a controlled outbound address.

Reference architecture in Azure

A straightforward Azure design contains:

  • A dedicated virtual network or suitably isolated subnet.
  • Two Windows Server virtual machines running the Microsoft Entra private network connector.
  • Both connectors registered in the same dedicated connector group.
  • No public IP addresses assigned directly to the virtual machines.
  • An Azure NAT Gateway associated with the connector subnet.
  • A static Standard public IP address assigned to the NAT Gateway.
  • Network controls allowing the connector service endpoints and the required SaaS destination.
flowchart TB
    A["Microsoft Entra Private Access"] --> B["Dedicated connector group"]
    B --> C["Connector 01"]
    B --> D["Connector 02"]
    C --> E["Connector subnet"]
    D --> E
    E --> F["Azure NAT Gateway"]
    F --> G["Static public IP"]
    G --> H["SaaS application"]

Azure NAT Gateway performs source network address translation for private resources in the associated subnet. The connector virtual machines can therefore reach the internet without public IP addresses of their own, while the destination consistently sees the static public IP attached to the NAT Gateway. Microsoft confirms that NAT Gateway public IP addresses are fixed in the Azure NAT Gateway FAQ.

NAT Gateway provides predictable outbound translation; it is not an outbound filtering product. If the design requires granular egress filtering, use appropriate network controls or Azure Firewall. Do not perform TLS interception on the connector’s communication with Microsoft services, as Microsoft advises against inline inspection and termination of that traffic.

Microsoft recommends at least two connectors in each connector group for high availability. Connectors within the group act as a unit for load balancing and resilience. More detail is available in Microsoft Entra private network connectors.

Two connector virtual machines protect against an individual server failure or maintenance event. If the application is business-critical, the wider design should also consider Azure regional failure, the NAT path and whether the SaaS provider can hold more than one approved egress IP.

Prerequisites

Before configuring source IP anchoring, you need:

  • Microsoft Entra Suite or Microsoft Entra Private Access licences for the users in scope.
  • The Microsoft Entra Private Access traffic forwarding profile enabled.
  • The current Global Secure Access client deployed to the endpoint.
  • At least one active private network connector, although two are recommended for production.
  • A stable outbound public IP address from the connector network.
  • Administrative access to add that public IP to the SaaS application’s allowlist.
  • The Global Secure Access Administrator, Application Administrator and Conditional Access Administrator roles as required for the relevant configuration steps.

The endpoint, connector and SaaS application must all be able to reach their required services before the route can work end to end.

Step 1: Build the controlled egress path

For the Azure reference design:

  1. Create the virtual network and a dedicated subnet for the connectors.
  2. Create a Standard public IP address.
  3. Create an Azure NAT Gateway and associate the public IP address with it.
  4. Associate the NAT Gateway with the connector subnet.
  5. Deploy two supported Windows Server virtual machines without public IP addresses.
  6. Install the Microsoft Entra private network connector on both servers.
  7. Register both connectors with Microsoft Entra and place them in the same connector group.
  8. Confirm that each connector reports as active.
  9. From the connector network, confirm that the SaaS application’s FQDN resolves and TCP 443 is reachable.
  10. Record the NAT Gateway public IP address that the SaaS provider will allowlist.

The private network connector only requires outbound connectivity. There is no reason to expose Remote Desktop or another management port directly to the internet. Use Azure Bastion, just-in-time access or an existing secure management path if interactive administration is required.

Step 2: Create the Private Access application

In the Microsoft Entra admin centre:

  1. Go to Global Secure Access > Applications > Enterprise applications.
  2. Select New application.
  3. Give the application a meaningful name, such as PA-SaaS-Vendor-Portal.
  4. Select the dedicated connector group.
  5. Add an application segment with the following settings:
    • Destination type: Fully qualified domain name
    • FQDN: The hostname of the SaaS application
    • Port: 443
    • Protocol: TCP
  6. Save the application.
  7. Assign the users or groups that require access.

Use a per-app Private Access application rather than adding the destination to Quick Access. The per-app model provides a clearer assignment boundary and allows Conditional Access policies to target this application specifically. Microsoft’s full portal process is documented in Configure per-app access using Global Secure Access applications.

Be precise with the application segment. Avoid routing an entire vendor domain through the connector when only one hostname requires the anchored address.

Step 3: Apply Conditional Access

The Private Access enterprise application can be selected as a Conditional Access target. This makes it possible to control who is authorised to use the anchored route and under what conditions.

A baseline policy might:

  • Include the users assigned to the Private Access application.
  • Exclude emergency access accounts where appropriate.
  • Require multifactor authentication or a suitable authentication strength.
  • Require the device to be marked as compliant.
  • Start in report-only mode before being enabled.

The exact policy should match the sensitivity of the SaaS application. An administrative or privileged application deserves stronger controls than a routine business service.

Microsoft documents the configuration path in Apply Conditional Access policies to Private Access apps.

Conditional Access protects access to the network route. The SaaS application must still authenticate the user and enforce its own application permissions.

Step 4: Allowlist the controlled egress IP

Add the static public IP assigned to the Azure NAT Gateway to the SaaS application’s network allowlist.

Do this before enforcing the new route if changing an existing production service. Retain a tested recovery path while the configuration is being validated, particularly where the SaaS platform’s administration page is protected by the same IP restriction being changed.

Once the allowlist is enforced, an assigned user with a healthy Global Secure Access client should reach the application through Private Access. A connection made outside that path should arrive from a different address and be rejected by the SaaS platform.

That gives the design a useful fail-closed property: disabling or bypassing the Global Secure Access client does not provide an alternate route into the application because the user’s normal internet address is not allowlisted.

Step 5: Validate the complete path

Do not stop after confirming that the web page opens. Validate each stage of the route.

On the endpoint, open Advanced Diagnostics in the Global Secure Access client:

  1. Open Forwarding profile.
  2. Expand the Private Access rules.
  3. Confirm that the SaaS FQDN appears in the list.
  4. Start a traffic capture from the Traffic section.
  5. Browse to the SaaS application.
  6. Stop the capture.
  7. Confirm that the destination FQDN is correct.
  8. Confirm that the channel is Private Access.
  9. Confirm that the action is Tunnel.

Then validate the destination:

  • Check the SaaS platform’s access or security logs.
  • Confirm that it sees the Azure NAT Gateway public IP.
  • Confirm that a device or user outside the assigned path is rejected.
  • Stop one connector and repeat the test to prove connector high availability.
  • Test authentication, logout, redirects and the application’s main workflows—not only its landing page.

These checks distinguish a working source IP anchoring design from a browser session that happened to succeed through another route.

Watch for additional FQDNs

A modern web application rarely talks to only one hostname. It might redirect the browser or load resources from separate authentication, API, content delivery or file-service domains.

For example:

  • portal.vendor.example
  • login.vendor.example
  • api.vendor.example
  • files.vendor.example

Only add the hostnames that must originate from the controlled IP. A public identity-provider endpoint normally does not need to be anchored merely because the main application does. Conversely, if an API endpoint performs the IP check and is missed from the application segment, the initial page might load while the application itself fails.

Use the Global Secure Access client diagnostics, browser developer tools and the SaaS provider’s documentation to map the required destinations. Be cautious with wildcard FQDNs because they can acquire considerably more traffic than intended.

QUIC, IPv6 and encrypted DNS

Traffic acquisition depends on the Global Secure Access client seeing and matching the destination correctly. Browser and operating-system features can change how that connection is established.

Microsoft’s source IP anchoring troubleshooting guidance currently calls out:

  • QUIC
  • IPv6
  • Encrypted DNS

An HTTPS application segment configured for TCP 443 will not match a browser attempting HTTP/3 over QUIC in the same way as a conventional HTTPS connection. Encrypted DNS or an unexpected IPv6 path can also make troubleshooting less obvious.

If the FQDN does not appear as a tunneled Private Access flow, test these areas before assuming the connector or NAT configuration is at fault. Any organisation-wide change to QUIC, IPv6 or DNS should still be assessed carefully rather than disabled indiscriminately.

Security and operational considerations

IP allowlisting is an additional control

The anchored IP establishes an approved network path. It should not become the application’s only security boundary. Retain strong user authentication, least-privilege authorisation, appropriate session controls and application logging.

Protect the egress address

Anything else using the same NAT Gateway public IP could also satisfy the SaaS application’s network check. A dedicated connector subnet and egress path make that trust boundary easier to understand and govern.

Plan for certificate inspection and firewalls

Connector communication to the Microsoft service should not be subjected to TLS interception. If Azure Firewall or another network virtual appliance is used, configure the required Microsoft destinations and the SaaS destination without terminating the connector’s Microsoft-bound TLS sessions.

Monitor connector health and capacity

Private network connectors are stateless, and the service directs new requests to available connectors in the group. Both connectors should be monitored, patched and kept on a supported version. A green connector status confirms service connectivity, but it does not prove that the SaaS destination is reachable from the connector network.

Consider latency

Source IP anchoring deliberately sends traffic through the connector network before it returns to the internet. Place the connectors and controlled egress somewhere sensible for the users and the SaaS service. Routing every request through a distant datacentre will work, but it may not provide a good user experience.

Document ownership

The solution crosses several operational boundaries: Global Secure Access, Conditional Access, Windows Server, Azure networking and the SaaS provider. Record who owns the connector group, static public IP, SaaS allowlist and recovery process. A future network change should not unexpectedly replace the address on which access depends.

When should you use this pattern?

Source IP anchoring is a good fit when:

  • A SaaS or line-of-business application enforces its own IP-based restrictions.
  • The service cannot accept the published Global Secure Access egress ranges.
  • You need a small set of organisation-controlled public IP addresses.
  • Users still need to reach the service from different locations.
  • You want to apply identity and device controls to the network route.

It is not necessary when the requirement exists only in Microsoft Entra Conditional Access. If the application uses Microsoft Entra authentication and the goal is simply to require users to connect through Global Secure Access, the compliant network control might meet the requirement without hairpinning application traffic through a connector network.

Final thoughts

IP allowlisting belongs to an older view of the security perimeter, but it remains a real requirement for many organisations and SaaS platforms.

Allowlisting the complete Global Secure Access /16 and /19 egress ranges is often technically possible but operationally unacceptable. Microsoft Entra Private Access provides a more controlled answer: acquire only the required application’s traffic, authorise the user and device through Microsoft Entra, route the connection through a private network connector and let the destination see a static public address that the organisation controls.

Using a dedicated pair of connectors with Azure NAT Gateway turns that capability into a clean and resilient design. It bridges a legacy network-based control with a modern identity-aware access platform without forcing remote users back onto a traditional VPN.

Further reading