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
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 a private endpoint in 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
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
To create a Private endpoint just follow up the procedure documented at https://docs.microsoft.com/en-us/azure/private-link/create-private-endpoint-portal
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
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
Server: UnKnown
Address: 168.63.129.16
Non-authoritative answer:
Name: westeurope1-a.control.database.windows.net
Address: 40.68.37.158
Aliases: fonsecanet-westeu.database.windows.net
After you create the Private Endpoint using the same command above you are expected to see the results below
Server: UnKnown
Address: 168.63.129.16
Non-authoritative answer:
Name: fonsecanet-westeu.privatelink.database.windows.net
Address: 10.0.1.4
Aliases: fonsecanet-westeu.database.windows.net
Be sure also to open outbound communication from 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
You must use the FQDN to connect to Azure SQL DB as documented at https://docs.microsoft.com/en-us/azure/sql-database/sql-database-private-endpoint-overview#check-con...
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
You can use some template like below to create the VPN Point to Site
After creating the VPN, downloading and installing the VPN client and connecting to it
If I check name resolution
nslookup fonsecanet-westeu.database.windows.net
We can see that it is still using Microsoft internal Corporate DNS where this VM is located
Server: XXXXXXXXXXX.corp.microsoft.com
Address: 10.221.xx.xx
Non-authoritative answer:
Name: westeurope1-a.control.database.windows.net
Address: 40.68.37.158
Aliases: fonsecanet-westeu.database.windows.net
fonsecanet-westeu.privatelink.database.windows.net
For this scenario you will need to use your corporate DNS to have the name resolution
https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-overview#dns-configuration
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:
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
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
For more information about more complex DNS relationships follow up the official documentation https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-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
- Go to DNS > Domain > Properties > Forwarders
- Add Azure DNS (168.63.129.16)
Do not forget to add virtual network link from Private Zone to the VNET where your Azure VM with DNS lives.
If you are have onprem DNS you may need a Conditional forwarder
Go to DNS > Domain > Conditional Forwarders > New
DNS Domain should be database.windows.net. DO NOT USE privatelink.database.windows.net
And you can check if name resolution works fine
nslookup fonsecanet-westeu.database.windows.net
Server: fonsecanetad.internal.cloudapp.net
Address: 10.0.0.5
Non-authoritative answer:
Name: fonsecanet-westeu.privatelink.database.windows.net
Address: 10.0.1.4
Aliases: fonsecanet-westeu.database.windows.net
If do not want to use forwarder you can also create a forward lookup zone and added manually the host to match the FQDN
To make Azure Function to connect to private endpoint you will need to use VNET integration
https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-vnet
https://docs.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet
*Status on (2020-04-27)
There was some limitation on webapp + private DBS that are now gone and just need to set some configurations as documented at https://docs.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet#azure-dns-private-z...
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:
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
You can check the source code at https://github.com/FonsecaSergio/AzureFunctionAppTestConnectivity
For this scenario I will just reference link from Product Group article https://techcommunity.microsoft.com/t5/azure-sql-database/using-failover-groups-with-private-link-fo...
Be sure to config private zone network link to both networks
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.
Result for my tests
C:\Users\FonsecaSergio>nslookup SERVER1.database.windows.net
Server: UnKnown
Address: 168.63.129.16
Non-authoritative answer:
Name: SERVER1.privatelink.database.windows.net
Address: 12.1.1.6
Aliases: SERVER1.database.windows.net
C:\Users\FonsecaSergio>nslookup SERVER2-westus.database.windows.net
Server: UnKnown
Address: 168.63.129.16
Non-authoritative answer:
Name: SERVER2-westus.privatelink.database.windows.net
Address: 11.0.1.4
Aliases: SERVER2-westus.database.windows.net
C:\Users\FonsecaSergio>nslookup FAILOVERGROUP.database.windows.net
Server: UnKnown
Address: 168.63.129.16
Non-authoritative answer:
Name: SERVER1.privatelink.database.windows.net
Address: 12.1.1.6
Aliases: FAILOVERGROUP.database.windows.net
SERVER1.database.windows.net
For DNS on more complex environments, please follow up other scenarios as mentioned at https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-dns
REF and LINKS
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.