Unable to Access Private Endpoints from App Service in Azure

Question

Unable to Access Private Endpoints from App Service in Azure

Krysynskyi Andrii MTAC-IRL 20

The App Service (Linux Container) with virtual network integration has suddenly stopped working. When attempting to run bash commands(from KUDO Console) for any of the private endpoints, the following errors occur:

dig 
connection timed out; no servers could be reached 
tcpping 
no response (timeout)

There are two virtual networks: one hub and one spoke. All private endpoints are located in the hub, while the App Service is integrated into the spoke VNet. The hub and spoke topology is managed by Azure Network Manager, and the connectivity configuration has been deployed, and peering created between the VNets.

Private DNS zones and links to networks are configured, and Azure DNS is being used.

When the connectivity configuration is removed and redeployed, nslookup and dig return proper results for a brief period, but tcpping continues to timeout. Eventually, nslookup and dig start timing out again.

This configuration was working properly until recently, and there have been no changes to the network configuration.

Any ideas on how to resolve this issue?

Thanks, Andrii

Krysynskyi Andrii MTAC-IRL 20 Reputation points

2025-03-18T13:17:26.71+00:00

Thanks for coming back to me,

I've double/triple checked all configuration and it looks ok to me.

As I said before DNS lookup works for a while after I remove configuration and redeploy it ( stops working if I restart App Service) but tcpping does not, so I am not sure why curl would, anyway I tried and it doesn't work.

Console output after re-deploying connectivity configuration:

After App Service restart:

We don't have anything that may be blocking traffic. I've tried to remove and re-add vnet integration but it doesn't help.

Azure Service Health looks ok as well.

Do you have any other ideas/suggestions?
Bodapati Harish 320 Reputation points Microsoft External Staff

2025-03-20T12:26:25.5066667+00:00
Hello Krysynskyi Andrii MTAC-IRL,

Thank you for providing the details. Below steps might help resolve the issue.

It seems like DNS resolution works temporarily after redeployment but stops after restarting the App Service. This could indicate that the App Service is not retaining DNS settings, or the networking configurations are not persisting correctly.

To confirm this, try forcing the DNS lookup using Azure’s default resolver:

nslookup <your-private-endpoint>.privatelink.database.windows.net 168.63.129.16

If this works initially but fails after a restart, check the App Service’s DNS settings and verify if a custom DNS setup is applied under Networking > VNet Integration > DNS Settings.

Also, confirm that the Private DNS Zone is properly linked to the spoke VNet. You can check this with:

az network private-dns link vnet list --zone-name <your-dns-zone> --resource-group <your-rg>

If the link is missing, re-add it and see if that helps.

For the tcpping issue, check connectivity using curl:

curl -v http://10.0.100.4

If curl works but tcpping still fails, check if NSG (Network Security Group) rules are blocking traffic. You can review the effective NSG rules applied to the private endpoint’s network interface:

az network nic list-effective-nsg --name <private-endpoint-nic-name> --resource-group <your-rg>

Your setup includes hub-spoke topology managed by Azure Network Manager, ensure that traffic forwarding is enabled in the peering settings. Even if DNS is resolving correctly, network traffic may not be routed properly.

Additionally, consider running a packet capture on the App Service using Azure Network Watcher to check if packets are reaching the private endpoint.

I hope this helps. Let me know if you need any further clarification, and I’ll be happy to assist you.
Krysynskyi Andrii MTAC-IRL 20 Reputation points

2025-03-20T17:53:47.08+00:00

Thanks for your support @Bodapati Harish .

We don't have any NSG or firewall in this case that may block traffic. Nor do we have custom DNS. In fact I've recreated the app with bicep script to ensure we don't have any special configuration in place.

curl output

nslookup output:

private dns zone:

Deployed Network Configuration

Network DNS

Peerings

from spoke to hub:

from hub to spoke:

App Service Networking:

The App Service is not working for a week now is there any chance someone at Microsoft support team could investigate it??
Bodapati Harish 320 Reputation points Microsoft External Staff

2025-03-21T09:01:45.07+00:00
Hello Krysynskyi Andrii MTAC-IRL,

Thanks for sharing the details. Few more troubleshooting steps that might help resolve your issue.

DNS Resolution: Run this inside the App Service container using SSH or Kudu:

nslookup <your-private-endpoint>.privatelink.database.windows.net nslookup <your-private-endpoint>.privatelink.database.windows.net 168.63.129.16

If the first fails but the second works, check if the App Service is set to inherit DNS settings from the VNet under Networking > VNet Integration > DNS Settings.

Connectivity to the Private Endpoint: From a VM in the same VNet, test if the private endpoint is reachable:

tcpping <private-endpoint-ip> 1433 # for SQL tcpping <private-endpoint-ip> 443 # for HTTPS

If tcpping is not available, try PowerShell:

Test-NetConnection -ComputerName <private-endpoint-ip> -Port 1433

If these fail, check NSG rules and routing.

Private DNS Zone Link: Verify that the Private DNS Zone is linked to the correct VNet:

az network private-dns link vnet list --zone-name <your-dns-zone> --resource-group <your-rg>

If missing, re-add it and restart the App Service.

VNet Peering & Traffic Forwarding: Check if VNet peering allows forwarded traffic:
az network vnet peering show --name <peering-name> --resource-group <your-rg> --vnet-name <your-vnet>
If AllowForwardedTraffic is false, enable it:
az network vnet peering update --name <peering-name> --resource-group <your-rg> --vnet-name <your-vnet> --set allowForwardedTraffic=true
Restart the App Service after applying changes. Packet Capture for Network Issues: Use Azure Network Watcher to capture packets and check if traffic is reaching the private endpoint.

I hope this helps. Let me know if you need any further clarification, and I’ll be happy to assist you.
Krysynskyi Andrii MTAC-IRL 20 Reputation points

2025-03-21T11:52:56.4466667+00:00

@Bodapati Harish

DNS Resolution: that's what I did and the ouptut is in my previous post

Private DNS Zone Link: screenshot is in my previous post

VNet Peering & Traffic Forwarding: screenshot is in my previous post

Packet Capture for Network Issues: how could traffic reach private endpoint if DNS query returns no results?

Connectivity to the Private Endpoint: We don't have any VMs I'll create one and see if it can reach the private endpoint from the hub VNET
Krysynskyi Andrii MTAC-IRL 20 Reputation points

2025-03-21T14:38:36.0766667+00:00

I've just noticed there is another virtual network with the same ip range (10.0.0.0/16) as the hub vnet, but they are not peered. Could it be the reason for the DNS lookup failure?
Bodapati Harish 320 Reputation points Microsoft External Staff

2025-03-21T15:53:35.5066667+00:00
Hello Krysynskyi Andrii MTAC-IRL,

Yes, having another virtual network with the same IP range (10.0.0.0/16) can definitely cause issues. Since they are not peered, it shouldn't directly affect the hub-spoke setup, but overlapping IP ranges can lead to unpredictable behavior in routing and DNS resolution.

You can check a few things:

Verify if the App Service is resolving the private endpoint to the correct IP by running nslookup <private-endpoint> from within the App Service.

From the VM in the hub VNet, try nslookup <private-endpoint> and tracert <private-endpoint-IP> to see the network path.

Ensure there are no unintended network policies, custom routes, or conflicting DNS settings that might be sending queries to the wrong VNet.

If possible, avoid overlapping IP ranges to prevent conflicts. Let me know if you need any further clarification, and I’ll be happy to assist you.
Bodapati Harish 320 Reputation points Microsoft External Staff

2025-03-24T04:38:02.09+00:00

Hello Krysynskyi Andrii MTAC-IRL,

Following up to see if you have chance to check my previous response and help us with requested information to check and assist you further on this.
Krysynskyi Andrii MTAC-IRL 20 Reputation points

2025-03-24T15:19:07.3366667+00:00

@Bodapati Harish I've dropped and recreated all resources with a script, so we don't have VNets with overlapping ip ranges anymore and App Service is working properly atm. It is just very weird that it stopped working after a month with no changes to the app itself or network.
Bodapati Harish 320 Reputation points Microsoft External Staff

2025-03-25T05:44:20.9233333+00:00

Hello Krysynskyi Andrii MTAC-IRL,

I’m happy to hear that your App Service is working properly now. It’s great that the steps helped in troubleshooting the issue. If the issue is cleared from above of my any suggestion, please try to accept the answer.

Accepted answer

0 additional answers

Your answer

Krysynskyi Andrii MTAC-IRL 20 Reputation points

2025-03-18T13:17:26.71+00:00

Thanks for coming back to me,

I've double/triple checked all configuration and it looks ok to me.

As I said before DNS lookup works for a while after I remove configuration and redeploy it ( stops working if I restart App Service) but tcpping does not, so I am not sure why curl would, anyway I tried and it doesn't work.

Console output after re-deploying connectivity configuration:

After App Service restart:

We don't have anything that may be blocking traffic. I've tried to remove and re-add vnet integration but it doesn't help.

Azure Service Health looks ok as well.

Do you have any other ideas/suggestions?
Bodapati Harish 320 Reputation points Microsoft External Staff

2025-03-20T12:26:25.5066667+00:00

Hello Krysynskyi Andrii MTAC-IRL,

Thank you for providing the details. Below steps might help resolve the issue.

It seems like DNS resolution works temporarily after redeployment but stops after restarting the App Service. This could indicate that the App Service is not retaining DNS settings, or the networking configurations are not persisting correctly.

To confirm this, try forcing the DNS lookup using Azure’s default resolver:

nslookup <your-private-endpoint>.privatelink.database.windows.net 168.63.129.16

If this works initially but fails after a restart, check the App Service’s DNS settings and verify if a custom DNS setup is applied under Networking > VNet Integration > DNS Settings.

Also, confirm that the Private DNS Zone is properly linked to the spoke VNet. You can check this with:

az network private-dns link vnet list --zone-name <your-dns-zone> --resource-group <your-rg>

If the link is missing, re-add it and see if that helps.

For the tcpping issue, check connectivity using curl:

curl -v http://10.0.100.4

If curl works but tcpping still fails, check if NSG (Network Security Group) rules are blocking traffic. You can review the effective NSG rules applied to the private endpoint’s network interface:

az network nic list-effective-nsg --name <private-endpoint-nic-name> --resource-group <your-rg>

Your setup includes hub-spoke topology managed by Azure Network Manager, ensure that traffic forwarding is enabled in the peering settings. Even if DNS is resolving correctly, network traffic may not be routed properly.

Additionally, consider running a packet capture on the App Service using Azure Network Watcher to check if packets are reaching the private endpoint.

I hope this helps. Let me know if you need any further clarification, and I’ll be happy to assist you.
Krysynskyi Andrii MTAC-IRL 20 Reputation points

2025-03-20T17:53:47.08+00:00

Thanks for your support @Bodapati Harish .

We don't have any NSG or firewall in this case that may block traffic. Nor do we have custom DNS. In fact I've recreated the app with bicep script to ensure we don't have any special configuration in place.

curl output

nslookup output:

private dns zone:

Deployed Network Configuration

Network DNS

Peerings

from spoke to hub:

from hub to spoke:

App Service Networking:

The App Service is not working for a week now is there any chance someone at Microsoft support team could investigate it??
Bodapati Harish 320 Reputation points Microsoft External Staff

2025-03-21T09:01:45.07+00:00

Hello Krysynskyi Andrii MTAC-IRL,

Thanks for sharing the details. Few more troubleshooting steps that might help resolve your issue.

DNS Resolution: Run this inside the App Service container using SSH or Kudu:

nslookup <your-private-endpoint>.privatelink.database.windows.net nslookup <your-private-endpoint>.privatelink.database.windows.net 168.63.129.16

If the first fails but the second works, check if the App Service is set to inherit DNS settings from the VNet under Networking > VNet Integration > DNS Settings.

Connectivity to the Private Endpoint: From a VM in the same VNet, test if the private endpoint is reachable:

tcpping <private-endpoint-ip> 1433 # for SQL tcpping <private-endpoint-ip> 443 # for HTTPS

If tcpping is not available, try PowerShell:

Test-NetConnection -ComputerName <private-endpoint-ip> -Port 1433

If these fail, check NSG rules and routing.

Private DNS Zone Link: Verify that the Private DNS Zone is linked to the correct VNet:

az network private-dns link vnet list --zone-name <your-dns-zone> --resource-group <your-rg>

If missing, re-add it and restart the App Service.

VNet Peering & Traffic Forwarding: Check if VNet peering allows forwarded traffic:
az network vnet peering show --name <peering-name> --resource-group <your-rg> --vnet-name <your-vnet>
If AllowForwardedTraffic is false, enable it:
az network vnet peering update --name <peering-name> --resource-group <your-rg> --vnet-name <your-vnet> --set allowForwardedTraffic=true
Restart the App Service after applying changes. Packet Capture for Network Issues: Use Azure Network Watcher to capture packets and check if traffic is reaching the private endpoint.

I hope this helps. Let me know if you need any further clarification, and I’ll be happy to assist you.
Krysynskyi Andrii MTAC-IRL 20 Reputation points

2025-03-21T11:52:56.4466667+00:00

@Bodapati Harish

DNS Resolution: that's what I did and the ouptut is in my previous post

Private DNS Zone Link: screenshot is in my previous post

VNet Peering & Traffic Forwarding: screenshot is in my previous post

Packet Capture for Network Issues: how could traffic reach private endpoint if DNS query returns no results?

Connectivity to the Private Endpoint: We don't have any VMs I'll create one and see if it can reach the private endpoint from the hub VNET
Krysynskyi Andrii MTAC-IRL 20 Reputation points

2025-03-21T14:38:36.0766667+00:00

I've just noticed there is another virtual network with the same ip range (10.0.0.0/16) as the hub vnet, but they are not peered. Could it be the reason for the DNS lookup failure?
Bodapati Harish 320 Reputation points Microsoft External Staff

2025-03-21T15:53:35.5066667+00:00

Hello Krysynskyi Andrii MTAC-IRL,

Yes, having another virtual network with the same IP range (10.0.0.0/16) can definitely cause issues. Since they are not peered, it shouldn't directly affect the hub-spoke setup, but overlapping IP ranges can lead to unpredictable behavior in routing and DNS resolution.

You can check a few things:

Verify if the App Service is resolving the private endpoint to the correct IP by running nslookup <private-endpoint> from within the App Service.

From the VM in the hub VNet, try nslookup <private-endpoint> and tracert <private-endpoint-IP> to see the network path.

Ensure there are no unintended network policies, custom routes, or conflicting DNS settings that might be sending queries to the wrong VNet.

If possible, avoid overlapping IP ranges to prevent conflicts. Let me know if you need any further clarification, and I’ll be happy to assist you.
Bodapati Harish 320 Reputation points Microsoft External Staff

2025-03-24T04:38:02.09+00:00

Hello Krysynskyi Andrii MTAC-IRL,

Following up to see if you have chance to check my previous response and help us with requested information to check and assist you further on this.
Krysynskyi Andrii MTAC-IRL 20 Reputation points

2025-03-24T15:19:07.3366667+00:00

@Bodapati Harish I've dropped and recreated all resources with a script, so we don't have VNets with overlapping ip ranges anymore and App Service is working properly atm. It is just very weird that it stopped working after a month with no changes to the app itself or network.
Bodapati Harish 320 Reputation points Microsoft External Staff

2025-03-25T05:44:20.9233333+00:00

Hello Krysynskyi Andrii MTAC-IRL,

I’m happy to hear that your App Service is working properly now. It’s great that the steps helped in troubleshooting the issue. If the issue is cleared from above of my any suggestion, please try to accept the answer.

Answer 1

Hello @Krysynskyi Andrii MTAC-IRL ,

The issue is that your App Service is having trouble resolving private endpoints and connecting over the network. Since this setup was working before, here are a few things you might want to check:

First, make sure the VNet peering and routing are still intact. The changes in the network configuration can impact connectivity.
Try running this command from Kudu to check if the private DNS resolution is working:

nslookup <your-private-endpoint>.privatelink.<service>.azure.com 168.63.129.16

If that fails, it could mean that your Private DNS zone is not correctly linked to both VNets.

Also, check if there are any NSGs, UDRs, or firewalls that might be blocking traffic from the App Service subnet to the private endpoint.
You can do a direct connectivity test using: curl -v http://<private-endpoint-ip>

If this works, then it's likely a DNS issue. If it doesn't, then it might be a network-related problem.

A simple restart of the App Service can help. If the issue persists, you could try removing and re-adding the VNet integration.
Finally, it might be worth checking Azure Service Health to see if there are any ongoing issues affecting App Service, VNet integration, or Private DNS.

Hope this helps! Let me know if you need any further details.

Please remember to "Accept Answer" if the solution has helped, so that others in the community facing similar issues can easily find the solution.

Krysynskyi Andrii MTAC-IRL 20 Reputation points

2025-03-20T09:42:47.2466667+00:00

Thanks for coming back to me,

I've double/triple checked all configuration and it looks ok to me.

As I said before DNS lookup works for a while after I remove configuration and redeploy it ( stops working if I restart App Service) but tcpping does not, so I am not sure why curl would, anyway I tried and it doesn't work.

Console output after re-deploying connectivity configuration:

After App Service restart:

We don't have anything that may be blocking traffic. I've tried to remove and re-add vnet integration but it doesn't help.

Azure Service Health looks ok as well.

Do you have any other ideas/suggestions?

Share via

Unable to Access Private Endpoints from App Service in Azure

0 additional answers

Your answer