Private Endpoints are the “final boss” of Azure networking troubleshooting. They are incredibly secure because they keep traffic off the public internet, but they introduce a layer of complexity—specifically around DNS resolution.

If your Private Endpoint isn’t working, 9 times out of 10, it’s a DNS issue.

---

1. The “DNS Trap” (Check this first!)

When you create a Private Endpoint for a service (like Azure SQL or Storage), the service still has a public FQDN (e.g., mydb.database.windows.net).

• The Problem: Your VM might be trying to connect to the Public IP instead of the Private IP of the endpoint.
• The Test: Run nslookup <your-resource-name>.database.windows.net from your client VM.
  • Fail: It returns a Public IP. Your VM is trying to go out to the internet.
  • Success: It returns a Private IP (e.g., 10.0.0.5).

The Fix: Ensure your Private DNS Zone is correctly linked to your Virtual Network and that the A-record for the resource exists.

---

2. Using Network Watcher for Private Endpoints

Once you’ve confirmed DNS is pointing to the right IP, use Network Watcher to see why the “handshake” is failing.

IP Flow Verify

Check if an NSG is blocking the traffic.

• Crucial Note: By default, Network Security Groups (NSGs) did not apply to Private Endpoints. However, Azure recently added a feature called “Network Policy for Private Endpoints.” * If this policy is Enabled on the subnet, your NSG could be blocking the traffic. Run IP Flow Verify to see if a “Deny” rule is stopping your VM from hitting the Private Endpoint’s IP.

Connection Troubleshoot

This is the most effective tool here because it tests the entire path.

• Setup: Set the Source as your VM and the Destination as the Private IP of the endpoint.
• What it reveals: It will tell you if the issue is a platform-level problem or a routing loop.

---

3. The “Hidden” Subnet Setting

A common “gotcha” when debugging Private Endpoints is the Subnet Private Endpoint Network Policy.

1. Go to your Virtual Network -> Subnets.
2. Click on the subnet where your Private Endpoint lives.
3. Look for “Private endpoint network policy”.
   • If you want to use NSGs to filter traffic to the Private Endpoint, this must be set to “Enabled”.
   • If it’s disabled, your NSGs are ignored for that endpoint, which can be a security hole (or a source of confusion during debugging).

---

4. Resource-Level Firewall

Even if the network is clear, the Target Resource (the SQL DB, the Key Vault, etc.) has its own internal “firewall” settings.

• The Debug Step: Go to the “Networking” blade of the resource itself (e.g., the Storage Account).
• The Check: Make sure “Public Network Access” is set to “Disabled” or “Enabled from selected virtual networks and IP addresses”, and ensure your Private Endpoint is listed as “Approved” in the Private Endpoint Connections tab.

---

Troubleshooting Checklist

Symptom	Probable Cause	Tool to Use
nslookup returns a Public IP	DNS Zone not linked to VNet	nslookup or dig
nslookup returns Private IP, but ping fails	NSG blocking traffic (if policy enabled)	IP Flow Verify
Connection works from one VNet but not another	Missing VNet Peering or DNS linking	Next Hop
Connection times out intermittently	Asymmetric routing or NVA interference	Packet Capture

---

Peer Tip: Don’t bother pinging a Private Endpoint. Most Azure PaaS services (like SQL or App Service) disable ICMP (ping) at the platform level. You can have a perfect connection and ping will still time out. Use Test-NetConnection -Port 443 (for HTTPS) or 1433 (for SQL) instead.

If are you seeing a “Connection Refused” error, or is the request simply timing out, that distinction usually tells you if the problem is the Firewall or the Routing.

When we talk about Private Endpoints, the “both” almost always refers to the two halves of the puzzle: DNS (the name) and Connectivity (the path). If one works but the other doesn’t, the connection fails.

---

1. The DNS Side (The “Who”)

This is where 90% of Private Endpoint issues live. You need your computer to look up mydb.database.windows.net and get a Private IP (like 10.0.0.5) instead of a Public IP.

How it works:

• The Private DNS Zone: Azure uses a special zone (e.g., privatelink.database.windows.net) to override the public internet record.
• Virtual Network Links: For your VM to “see” that private zone, the Private DNS Zone must be linked to the Virtual Network where the VM lives.
• The CNAME Magic: Azure uses a CNAME chain. It goes:mydb.database.windows.net -> mydb.privatelink.database.windows.net -> 10.0.0.5.

Troubleshooting the DNS “Half”:

• The Tool: Use nslookup or dig.
• The “Tell”: If you see a public IP or an error saying the name can’t be resolved, your VNet Link is missing or your DNS server (if using custom DNS) isn’t forwarding requests to the Azure WireServer IP (168.63.129.16).

---

2. The Connectivity Side (The “How”)

Even if you have the right IP, the “wires” (virtual or otherwise) must allow the traffic to flow.

The Key Hurdles:

• NSG Support (Network Policy): By default, Network Security Groups (NSGs) ignore Private Endpoints. If you want to block or allow traffic to a Private Endpoint using an NSG, you must Enable Private Endpoint Network Policy on the subnet.
• VNet Peering: If your VM is in VNet A and your Private Endpoint is in VNet B, you need VNet Peering set up. Furthermore, VNet A must also be linked to the Private DNS Zone in VNet B.
• The Resource Firewall: Some services (like Storage Accounts) have a “Firewalls and Virtual Networks” tab. You must ensure that “Public Network Access” is disabled or restricted, but the Private Endpoint Connection itself is marked as Approved.

---

How to Debug “Both” Simultaneously

If you are staring at a “Timed Out” error, follow this logic:

1. Test DNS: Run nslookup.
   • Public IP? Fix your DNS Private Zone/Linking.
   • Private IP? DNS is fine; move to step 2.
2. Test the Path: Run Test-NetConnection -ComputerName <FQDN> -Port 443.
   • TcpTestSucceeded : False? You have a routing or NSG issue.
   • TcpTestSucceeded : True? The network is perfect; the problem is likely your application’s credentials or configuration.

---

Comparison at a Glance

Component	Goal	Primary Failure Mode
DNS	Translate the URL to a 10.x.x.x IP.	Returning a Public IP (Internet-facing).
Connectivity	Get the packet from VM to that IP.	NSG “Deny” rules or missing VNet Peerings.

---

Peer Tip: When setting up Private Endpoints for a team, always use Azure Private DNS Zones integrated with the service. If you try to manage host files on individual VMs to “hack” the DNS, you will create a maintenance nightmare that will eventually break.