Azure URL app service not working in vnet with private endpoint-CodePudding

Hi currently I have setup a VNET. Inside this vnet I made a VM and I added an App-Service in the subnet with an private-endpoint. The private-endpoint of the App-Service is also automatically added to a privatelink DNS zone. (Azure created this automatically for me) It also points correctly to the right internal ip address. Now from within my VM I try to access my AppService using curl and using the created .privatelink.azurewebsites.net link to the AppService. But it keeps returning 404. How is this possible. My knowledge of DNS is limited.

If I do a NSLOOKUP inside the VM, it nicely resolves the privatelink DNS Name and finds the private-endpoint ip address What am I missing?

Update When I keep using the original azurewebsites.net xxxxxxx.azurewebsites.net (not the privatelink) URL I can access the appservice from within the VNET. If I am on the VM, and I do a lookup of the original URL I get this.

Non-authoritative answer:
xxxxxxxxx.azurewebsites.net       canonical name = xxxxxxxxx.privatelink.azurewebsites.net.
Name:  xxxxxxxx.privatelink.azurewebsites.net
Address: 10.1.1.4

So there is some magic behind the scenes?

CodePudding user response：

When you create a public Azure App Service "xxxxxxxxx", beside provisioning the app service environment also a DNS entry for this new service will be created in one of Microsoft's authoritative DNS servers (they are usually named like ns1-xxx.azure-dns.com) ultimately pointing to the public IP address of the server where your your app service is hosted.

If you add a private endpoint for your app service, the DNS entry in these servers won't be removed. Instead what's happening is that internet access to your web app is cut off using firewall rules.

This means if you type in "xxxxxxxxxx.azurewebsites.net" in your browser outside the VNet, a DNS query is sent and the public IP address of the server is returned. Your browser sends a HTTP query to that IP address but will get a HTTP status code 403 indicating that public traffic is blocked.

Inside your VNet the situation is different. As you described you got a private DNS zone "privatelink.azurewebsites.net" which is linked to the VNet (you can see that in the "Virtual network links" section)

If you now type "xxxxxxxxxx.azurewebsites.net" in a browser in your VM which is placed in the same VNet as xxxxxxxxxx.azurewebsites.net, the DNS server associated with the network adapters (by default accessible in your VM through 168.63.129.16) will use the entries placed in the private DNS zones. If a zone named "privatelink.azurewebsites.net" exists, all queries for the domain "azurewebsites.net" will be resolved using this private DNS zone. For example, if there is an A record entry for "xxxxxxxxxx" for 172.16.0.5...

...this is exactly the IP you'll get when you resolve xxxxxxxxxx.azurewebsites.net in your Azure VM:

C:\Users\vm>nslookup xxxxxxxxxx.azurewebsites.net
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
Name:    xxxxxxxxxx.privatelink.azurewebsites.net
Address:  172.16.0.5
Aliases:  xxxxxxxxxx.azurewebsites.net

If you delete your private DNS zone, the DNS server will resolve back to ns1-xxx.azure-dns.com which in turn will give you the public IP of the service:

C:\Users\vm>nslookup xxxxxxxxxx.azurewebsites.net
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
Name:    waws-prod-am2-459-d21a.westeurope.cloudapp.azure.com
Address:  20.50.2.66

But since the app service still has firewall rules applied that block all traffic coming from outside the VNet, you will get a HTTP status code of 403 if you try to access the service over a browser.