Azure SQL: can’t ping the Private Endpoint from on-prem

I’ve set up an Azure SQL PaaS server and a private endpoint (PE) so I can connect privately over our VPN. However I can’t ping the endpoint IP from my on-premise client. As the ping command isn't supported (as PE doesn't support ICMP traffic - see FAQ), I used psping too. My set up is below, I’d like some advice on what I’m missing.

Architecture: on-prem VPN Connected via S2S VPN to an Azure Hub and Spoke environment (1 Hub Subscription+Vnet, 3 Spoke Subs+VNets. All spoke Vnets peered with Hub Vnet).

PE deployed to one of the spokes, into a Subnet (no delegation, but I’ve checked on the Microsoft.Sql service). PE uses a Private DNS Zone in the Hub Sub which has Vnet links enabled to the Hub and Spoke VNets. The A name records exist for DNS purposes (but in this case I'm just trying to test IP connectivity).

I’ve also registered Microsoft.Networks and Microsoft.Sql resource providers on all Subs.

Azure SQL has public access turned off, and has an (approved) PE listed as a private connection method.

On my on-prem laptop, I expect to be able to open cmd and psping the ip of the PE but it always times out. Why can’t I do it? (FYI- for FQDN resolution, we have an on-prem DNS server, but as this is externally managed I’m yet to ask them to create the conditional forwarder to the Azure DNS private resolver for DNS lookup. I want to test the ip ping first. We have some private (VNet injected) PostgreSQL Flexible servers in the Spoke VNets which I can successfully ping using their IPs). Thanks

I've successfully managed to connect to/ping the FQDN of my private Azure SQL server from an on-premise client machine. I'll list all the requirements in this answer:

• an Azure SQL Server (assigned to one of the Spoke Subscriptions, public access disabled, private access enabled & set to the Private Endpoint described below)
• an Azure SQL Database (attached to the server)
• a Subnet* (adding the Microsoft.Sql service endpoint has no effect in my scenario, but I have it enabled anyway)
• a Private Endpoint (deployed into one of my Spoke VNets, into the Subnet above, integrated with the Private DNS Zone below, with target sub-resource set to sqlServer)
• a Private DNS Zone (containing A type record to the SQL server name and Private Endpoint private IP address, associated to the Hub Subscription, with Virtual network links to the Hub VNet, and all 3 spoke VNets)
• for each Subscription, in Resource providers blade, make sure Microsoft.Network (for Private Endpoint usage) and Microsoft.Sql (for Azure SQL usage) are registered
• an Azure based DNS forwarder (VM or DNS Private Resolver) located in the Hub VNet
• a Conditional Forwarder added to the on-premise custom DNS Server, directing queries for database.windows.net to the inbound endpoing IP address of the Azure DNS forwarder

*the Subnet may need a NSG and Route table assigned to it, depending on your Azure setup.

For me, this entire solution enabled on-premise private connectivity to an Azure SQL database. I then could psping fqdn:port (normal ping command won’t work for PEs). I hope others find this useful. Relevant MS documentation links here (see second image down) and here.

Relevant images from these articles: