We moved our Azure app into a VNet, and now we cannot connect to 3rd-party SQL Azure databases that have their own (unrelated) private endpoints

We run a SaaS which puts data in other people's SQL Azure databases. These databases are 3rd-party and out of our control - we asked only that they whitelist our IP addresses.

Recently, we added our app to a VNet and obtained a fixed IP for ourselves. We asked our customers to whitelist the new IP address. For most, there was no problem.

However, some customers have their database within their own VNet and use private endpoints to grant access to their other systems. We have found that our app is incapable of connecting to these databases until they remove their private endpoint. Here, I am accessing the console from my Azure App and connecting to a 3rd-party database - both with and then without a private-endpoint:

You can see the first one resolves to just the "privatelink" alias, but the second returns more info including an IP address.

SQL Redirection

At first I thought it was the SQL Redirect connection policy, so I added an NGS and outgoing rule to my own VNet, as per the various articles online that discuss SQL Redirection:

This has not made a difference.

Firewall

I already had our customers whitelist our new IP address. It is worth noting though that in my own tests (with a compliant client) even if I open up the firewall to ALL IP addresses briefly, we still do not gain access. Nor do we gain access if we check the "Allow Azure Services" box. I believe this indicates that we simply cannot resolve the name in the first place, so aren't even getting to the firewall yet (?)

Outbound application routing

I do also note that the behaviour can be avoided if I disable the routing of all outbound traffic:

• With this box checked, the behaviour above stands
• With this box unchecked, I can now access the database in the 3rd-party system but it originates from an IP address that is NOT the fixed IP address in my VNet. To confirm this behaviour, note the change in result when I ping from with the Azure Console:

One of the reasons we configured the VNet in the first place is so that we could use a fixed IP, so option two is not suitable. What I believe is interesting though is that it is only when we internally route the calls to xyz.database.windows.net that the DNS appears to completely fall over. Perhaps I have to add some other kind of route/mapping/DNS to "restore" this domain name?

To summarize

• our system worked fine until we had our own VNet
• once we changed to a VNet, those customers who had standalone SQL Azure databases continued to work fine (once they added our new IP address)
• but those customers whose databases had their own (unrelated) private endpoint are NOT working
• however, if I allow Azure to route traffic outside of my network (via the Application Routing checkbox), then the 3rd-party databases are accessible again

What I need

This is a SaaS, so I cannot manually wire up private endpoints to each and every client database at our end. I need either:

• a single change I can make to my own VNet, to enable this connectivity (preferred); or
• an instruction I can provide to my customers that would enable them to grant access to our new VNet

Thanks

We ended up working around this issue instead of resolving it completely. When you create a private endpoint, Azure will also create a "Private DNS Zone" for privatelink.database.windows.net, and add your VNET to it:

The name of this tied in, of course, with the results you get from running pings against the server (from outside of our VNET). Given that our ping from within the VNET (see screenshots above) were returning "...could not find host", we speculated that perhaps this private DNS zone was rerouting ALL requests to *.privatelink.database.windows.net to within our VNET. Sure enough, when we de-linked our VNET from this zone, the connection worked again.

The issue then of course was that our own private endpoint didn't work, but we were able to get around that simply by adding service endpoints instead:

I assume this means there is no longer a private DNS zone inside our network and thus Azure will look outside our network to continue resolving it.

It is good that we are able to get past this issue, but I still feel like there must be a way to support private links both within one's own VNET with no concern for how a 3rd-party might also be using private links.

I'm also a little concerned that one day in the future we'll have our own requirement for a private endpoint and we won't be able to utilize it.

If anybody can address the first scenario for us, that would still be of great interest.