PE can't accessed from onprem

The most likely cause is routing from on-premises to VNET2 through VNET1, not the private endpoint itself.

Based on the tests:

1. On-prem can RDP to a VM in VNET2
   • This shows on-prem to VNET2 connectivity exists for at least that VM path.
2. A VM inside VNET2 can access the private endpoint
   • This shows the private endpoint and storage-side private link are working inside Azure.
3. A VM in VNET1 can access the private endpoint in VNET2
   • This shows VNET peering between VNET1 and VNET2 is working for Azure-to-Azure traffic.

That narrows the issue to the on-prem to VNET2 private endpoint path.

For this topology, check these items:

1. Verify routing from on-prem to VNET2
   • When on-prem reaches VNET2 through VNET1, a static route from the on-prem side may be required so that both VNET1 and VNET2 prefixes point to the same VPN path.
   • Also verify there is no IP overlap between on-prem, VNET1, and VNET2.
2. Check whether the source is on-prem and the destination is a private endpoint in Azure
   • The recommended isolation step is:
     • try connecting from on-prem to another VM in the Azure virtual network
     • try connecting from a VM in the virtual network to the private endpoint
   • Those tests already show the issue is specific to the on-prem path to the private endpoint.
3. Validate DNS from on-prem
   • For private endpoints, name resolution must return the private IP.
   • From the same on-prem network, verify the storage account FQDN resolves to the private endpoint IP.
   • If on-prem uses a DNS forwarder, review that configuration and confirm the query returns the expected private IP.
4. Check effective routing on the source side
   • The source VM should have a route to the private endpoint IP with next hop InterfaceEndpoints.
   • If the private endpoint route is missing and the source VM and private endpoint are in different VNets that are not directly peered, check IP connectivity between the VNets.
5. If VNET1 and VNET2 are directly peered and the route to the private endpoint still does not appear, engage support
   • The documented guidance is:
     • if source VM and private endpoint are in the same VNet and the private endpoint route is missing, engage support
     • if they are in different VNets that are directly peered and the route is missing, engage support

Important detail: a private endpoint is not the same as a normal VM NIC. Even if a VM in VNET2 is reachable from on-prem, the private endpoint path can still fail because of DNS or route handling specific to private endpoint traffic.

A practical next step sequence is:

1. From on-prem, resolve the storage account FQDN and confirm it returns the private endpoint IP.
2. Confirm on-prem routing includes the VNET2 prefix toward Azure, not only VNET1.
3. Confirm no overlapping address spaces exist.
4. If VNET2 is reached through VNET1, add or verify the required static route on the on-prem side for both VNET1 and VNET2.
5. If routing and DNS are correct but the private endpoint path still fails, open a support case.

Also, the IP in the question appears inconsistent:

• private endpoint mentioned as 10.215.1.5
• later referenced as 10.215.1.4

Verify the actual private endpoint IP first before testing.

• Troubleshoot Azure Private Endpoint connectivity problems
• Troubleshooting private endpoint configuration for Microsoft Purview accounts
• Vnet Peering - Microsoft Q&A