Use Private Link in Virtual WAN
Azure Private Link is a technology that allows you to connect Azure Platform-as-a-Service offerings using private IP address connectivity by exposing Private Endpoints. With Azure Virtual WAN, you can deploy a Private Endpoint in one of the virtual networks connected to any virtual hub. This private link provides connectivity to any other virtual network or branch connected to the same Virtual WAN.
Before you begin
The steps in this article assume that you've deployed a virtual WAN with one or more hubs and at least two virtual networks connected to Virtual WAN.
To create a new virtual WAN and a new hub, use the steps in the following articles:
Routing Considerations with Private Link in Virtual WAN
Private Endpoint connectivity in Azure is stateful. When a connection to a private endpoint gets established through Virtual WAN, traffic is routed through one or more traffic hops through different Virtual WAN components (for example Virtual Hub router, ExpressRoute Gateway, VPN Gateway, Azure Firewall, or NVA). The exact hops traffic takes is based on your Virtual WAN routing configurations. Behind the scenes, Azure's software-defined networking layer sends all packets related to a single 5-tuple flow to one of the backend instances servicing different Virtual WAN components. Asymmetrically routed traffic (for example, traffic corresponding to a single 5-tuple flow routed to different backend instances) is not supported and is dropped by the Azure platform.
During maintenance events on Virtual WAN infrastructure, backend instances are rebooted one at a time, which can lead to intermittent connectivity issues to Private Endpoint as the instance servicing the flow is temporarily unavailable. The similar problem can occur when Azure Firewall or Virtual hub router scales out. The same traffic flow can be load-balanced to a new backend instance that is different than the instance currently servicing the flow.
To mitigate the impact of maintenance and scale-out events on Private Link or Private Endpoint traffic consider the following best practices:
- Configure the TCP time-out value of your on-premises application to fall between 15-30 seconds. A smaller TCP time-out value will allow application traffic to recover more quickly from maintenance and scale-out events. Alternatively, test different application time-out values to determine a suitable time-out based on your requirements.
- Pre-scale Virtual WAN components to handle traffic bursts to prevent autoscale events from occurring. For the Virtual Hub router, you can set the minimum routing infrastructure units on your hub router to prevent scaling during traffic bursts.
Lastly, if you are using on-premises connectivity between Azure and on-premises using VPN or ExpressRoute, ensure your on-premises device is configured to use the same VPN tunnel or same Microsoft Enterprise Edge router as the next-hop for each 5-tuple corresponding to private endpoint traffic.
Create a private link endpoint
You can create a private link endpoint for many different services. In this example, we're using Azure SQL Database. You can find more information about how to create a private endpoint for an Azure SQL Database in Quickstart: Create a Private Endpoint using the Azure portal. The following image shows the network configuration of the Azure SQL Database:
After creating the Azure SQL Database, you can verify the private endpoint IP address browsing your private endpoints:
Clicking on the private endpoint we've created, you should see its private IP address and its Fully Qualified Domain Name (FQDN). The private endpoint should have an IP address in the range of the VNet (10.1.3.0/24):
Verify connectivity from the same VNet
In this example, we verify connectivity to the Azure SQL Database from a Linux virtual machine with the MS SQL tools installed. The first step is verifying that DNS resolution works and the Azure SQL Database Fully Qualified Domain Name is resolved to a private IP address, in the same VNet where the Private Endpoint has been deployed (10.1.3.0/24):
nslookup wantest.database.windows.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
wantest.database.windows.net canonical name = wantest.privatelink.database.windows.net.
Name: wantest.privatelink.database.windows.net
Address: 10.1.3.228
As you can see in the previous output, the FQDN wantest.database.windows.net is mapped to wantest.privatelink.database.windows.net, that the private DNS zone created along the private endpoint will resolve to the private IP address 10.1.3.228. Looking into the private DNS zone will confirm that there's an A record for the private endpoint mapped to the private IP address:
After verifying the correct DNS resolution, we can attempt to connect to the database:
query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"
10.1.3.75
As you can see, we're using a special SQL query that gives us the source IP address that the SQL server sees from the client. In this case the server sees the client with its private IP (10.1.3.75), which means that the traffic goes from the VNet straight into the private endpoint.
Set the variables username and password to match the credentials defined in the Azure SQL Database to make the examples in this guide work.
Connect from a different VNet
Now that one VNet in Azure Virtual WAN has connectivity to the private endpoint, all of the other VNets and branches connected to Virtual WAN can have access to it as well. You need to provide connectivity through any of the models supported by Azure Virtual WAN, such as the Any-to-any scenario or the Shared Services VNet scenario, to name two examples.
Once you have connectivity between the VNet or the branch to the VNet where the private endpoint has been deployed, you need to configure DNS resolution:
- If connecting to the private endpoint from a VNet, you can use the same private zone that was created with the Azure SQL Database.
- If connecting to the private endpoint from a branch (Site-to-site VPN, Point-to-site VPN or ExpressRoute), you need to use on-premises DNS resolution.
In this example we're connecting from a different VNet. First attach the private DNS zone to the new VNet so that its workloads can resolve the Azure SQL Database Fully Qualified Domain Name to the private IP address. This is done through linking the private DNS zone to the new VNet:
Now any virtual machine in the attached VNet should correctly resolve the Azure SQL Database FQDN to the private link's private IP address:
nslookup wantest.database.windows.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
wantest.database.windows.net canonical name = wantest.privatelink.database.windows.net.
Name: wantest.privatelink.database.windows.net
Address: 10.1.3.228
In order to double-check that this VNet (10.1.1.0/24) has connectivity to the original VNet where the private endpoint was configured (10.1.3.0/24), you can verify the effective route table in any virtual machine in the VNet:
As you can see, there's a route pointing to the VNet 10.1.3.0/24 injected by the Virtual Network Gateways in Azure Virtual WAN. Now we can finally test connectivity to the database:
query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"
10.1.1.75
With this example, we've seen how creating a private endpoint in one of the VNets attached to a Virtual WAN provides connectivity to the rest of VNets and branches in the Virtual WAN.
Next steps
For more information about Virtual WAN, see the FAQ.