In the article Azure SQL DB Connectivity Troubleshooting we have explored regular connectivity troubleshooting to Azure SQL DB, on this one we will explore connectivity troubleshooting using Private Link
In this article we are going to explore
What is the Private Endpoint for Azure DB?
Creation of Private Endpoint
Azure VM > Private Link
OnPrem VM > VPN (P2S) > Private Link (Hosts File)
OnPrem VM > VPN (P2S) > Private Link (Custom DNS)
Azure Function > VNET integration > Private Endpoint
Failover Groups with Private Link
1 - What is the Private Endpoint for Azure DB?
Azure Private Link enables you to access Azure PaaS Services (for example, Azure Storage and SQL Database) and Azure hosted customer-owned/partner services over aprivate endpointin your virtual network.
Traffic between your virtual network and the service travels the Microsoft backbone network. Exposing your service to the public internet is no longer necessary
Some important information
Private Link service can be accessed from approved private endpoints in the same region. The private endpoint can be reached from the same virtual network, regionally peered VNets, globally peered VNets and on premises using private VPN or ExpressRoute connections.
When creating a Private Link Service, a network interface is created for the lifecycle of the resource. This interface is not manageable by the customer.
The Private Link Service must be deployed in the same region as the virtual network.
A single Private Link Service can be accessed from multiple Private Endpoints belonging to different VNets, subscriptions and/or Active Directory tenants. The connection is established through a connection workflow.
In the image, below we can see how the connection using private endpoint works. And as mentioned on the other article Azure SQL DB Connectivity Troubleshooting the Azure SQL DB clients by default will all go to the Shared public IP of the regional gateway.
With the private endpoint you can close this public path and users can only connect from private endpoint.
If you have multiple Azure VNETs you will need to use VNET peering or VNET VPN between two Azure VNETs, or P2S,S2S or Express Route to connect your onprem to Azure Network
You may also want to close all public network access to make sure all connection must flow from Private Endpoint. Just need to go to Azure SQL DB instance and "Firewall and Virtual Networks" and Deny public network access.
Find below the procedure I've used to create a Private Endpoint
Just need to go to "Private Endpoint Connections" and then add a Private endpoint
Select the region that should be the same as the VNET region as mentioned above.
Select the resource type "Microsoft.Sql/servers" for Azure SQL DB instance
Select the Azure SQL DB instance you want to connect
Select the VNET / Subnet. Notice also that during the creation you can already create a private DNS zone, that will work for Azure resources that uses the Azure DNS. We will talk more about that when doing the tests
3 - Azure VM > Private Endpoint
From an Azure VM deployed to same VNET, if we test command below on command prompt before you create the Private Endpoint.
nslookup fonsecanet-westeu.database.windows.net
You will get result like below that shows that this server is using public gateway IP: 40.68.37.158. So NOT using any private IP
Be sure also to open outbound communicationfrom Azure VM VNET to Private Endpoint on Local Firewall, Corporate Firewall, or Azure NSGs. For this test I've opened to allow all communication inside VNET.
*Currently (Status on 2020-04-06) redirect is not supported, so only needed 1433 port
Use the Fully Qualified Domain Name (FQDN) of the server in connection strings for your clients. Any login attempts made directly to the IP address shall fail. This behavior is by design, since private endpoint routes traffic to the SQL Gateway in the region and the FQDN needs to be specified for logins to succeed.
You can also check if connection is correct using TSQL below. And we will see the client IP is the private IP assigned to Azure VM.
SELECT client_net_address FROM sys.dm_exec_connections where session_id = @@SPID
You must use the FQDN to connect to Azure SQL DB. Azure SQL DB gateway use the name to route correctly your connection to the SQL host, when information is not provided it will fail
If you try to connect using private endpoint IP you are going to get error like below
=================================== Cannot connect to 10.0.1.4. =================================== A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - The target principal name is incorrect.) (.Net SqlClient Data Provider) ------------------------------ Server Name: 10.0.1.4 Error Number: -2146893022 Severity: 20 State: 0
You should also NOT use DB.privatelink.database.windows.net
=================================== Cannot connect to fonsecanet-westeu.privatelink.database.windows.net. =================================== A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - The target principal name is incorrect.) (.Net SqlClient Data Provider) ------------------------------ Server Name: fonsecanet-westeu.privatelink.database.windows.net Error Number: -2146893022 Severity: 20 State: 0
4 - OnPrem VM > VPN (P2S) > Private Link (Hosts File)
You can use some template like below to create the VPN Point to Site
When connecting to a private link resource using a fully qualified domain name (FQDN) as part of the connection string, it's important to correctly configure your DNS settings to resolve to the allocated private IP address. Existing Azure services might already have a DNS configuration to use when connecting over a public endpoint. This needs to be overridden to connect using your private endpoint.
The network interface associated with the private endpoint contains the complete set of information required to configure your DNS, including FQDN and private IP addresses allocated for a given private link resource.
You can use the following options to configure your DNS settings for private endpoints:
Use the Host file (only recommended for testing). You can use the host file on a virtual machine to override the DNS.
Use a private DNS zone. You can use private DNS zones to override the DNS resolution for a given private endpoint. A private DNS zone can be linked to your virtual network to resolve specific domains.
Use your custom DNS server. You can use your own DNS server to override the DNS resolution for a given private link resource. If your DNS server is hosted on a virtual network, you can create a DNS forwarding rule to use a private DNS zone to simplify the configuration for all private link resources.
Important
It's not recommended to override a zone that is actively in use to resolve public endpoints. Connections to resources won't be able to resolve correctly without DNS forwarding to the public DNS. To avoid issues, create a different domain name or follow the suggested name for each service below.
Private Link resource type
Subresource
Zone name
SQL DB (Microsoft.Sql/servers)
Sql Server (sqlServer)
privatelink.database.windows.net
Azure will create a canonical name DNS record (CNAME) on the public DNS to redirect the resolution to the suggested domain names. You'll be able to override the resolution with the private IP address of your private endpoints.
Your applications don't need to change the connection URL. When attempting to resolve using a public DNS, the DNS server will now resolve to your private endpoints. The process does not impact your applications.
For this test will use HOST file solution
And we are able to connect fine. And as before you will be able to check you get the VPN ip range using TSQL below
SELECT client_net_address FROM sys.dm_exec_connections where session_id = @@SPID
5 - OnPrem VM > VPN (P2S) > Private Link (Custom DNS)
If you do not want to use local hosts file as mentioned above you can add Azure DNS (168.63.129.16) as a forwarder on your custom DNS
On Azure Virtual Network settings I've replaced default Azure DNS with your custom DNS (On my tests 10.0.0.5). You can also add 168.63.129.16 (Azure DNS) as secondary DNS just in case 1st is off
If your client lives in Azure, the DNS on VM can be a forwarder to Azure DNS
After your app integrates with your VNet, it uses the same DNS server that your VNet is configured with. By default, your app won't work with Azure DNS Private Zones. To work with Azure DNS Private Zones you need to add the following app settings:
WEBSITE_DNS_SERVER with value 168.63.129.16
WEBSITE_VNET_ROUTE_ALL with value 1
These settings will send all of your outbound calls from your app into your VNet in addition to enabling your app to use Azure DNS private zones.
And I've also created a sample Azure Function app that accept the connection string as parameter and was able to connect fine
This model can be extended to multiple peered virtual networks that are associated to the same private endpoint. This can be done by adding new virtual network links to the private DNS zone for all peered virtual networks.
Referring to the scenario "5 OnPrem -> VPN -> Azure Private Link (Custom DNS)", you mention that by adding the forwarder to the Azure DNS 168.63.129.16, requests to FQDN of sql server should be able to resolve.
FonsecaSergio great article! we have intermittent issues with on-prem VM to SQL PE by using Azure DNS private resolver. can this article be updated with some best practices for trouble shooting with the Azure DNS private resolver architecture?
Thank you for great article, I have a question though on how the connection string should look like in case when we have Private Endpoints on a Failover.
We have an ASP.Net Web app hosted as Azure App serivce connecting to Azure SQL Server. We have 2 Azure SQL Server one in North and other in South region (For Failover). We have created Private endpoints for both the sql servers:-
Following is the Read/Write listener endpoint from Failover group:-
XXXXX-devxxxxs-failovergroup.database.windows.net
North is Primary and South is secondary and they are added to Failover group. AsP.Net Web app connection string uses private endpoint to North Region SQL Server as follows:-
We did a Failover test and SQL Server were switched as South primary and North secondary but our suspicion was its still connecting to North region database due to pvt endpoint so for testing we delted north region database and we got runtime exception.
Then I changed my connection string to use the READ/WRITE Listner and this is how my connection string looked (same user id and password) and still we got runtime exception : Cannot connect to the database. following was the modified connection string using the listener endpoint from failover group:-
My question here is what should the connection string look like in this scenario where I have 2 SQL Servers in 2 different regions with Private EndPoints and in the Failover group. I am not sure about what should be the Database Server name that goes in web.config connection string so that it can automatically connect to the Secondary Server if Primary Server goes down.
But considering what you said the problem could be related to DNS Name and TTL (Time to Live)... When you get a DNS registry it will be valid for usually 1h. If client is a VM you could do a IPCONFIG /flushdns... If webapp, a service restart probably may do the trick, or just need to wait for the TTL.
You can validate it using Kudu on WebApp and trying to check name resolution NSLOOKUP failoverserver.database.windows.net. It should point first to one region gateway, then to other one. Here is a sample of a NSLOOKUP I done on my failover name... You can see that currently lead to West Eu
Thank you FonsecaSergio and I tried to do the same nslookup and it works perfectly from nslookup resolving properly as shown below in the screenshot but unfortunately the web-app is still complaining on cannot connect to the database when I am using the Failover group Listener endpoint with User Name and Password from Primary SQL Server.