That's correct - at this time, Azure SQL Database firewall rules only support IPv4 addresses and ranges. You cannot add or whitelist IPv6 addresses or CIDR blocks like — the portal, ARM templates, CLI, and PowerShell will all reject them with the “must be a valid IPv4 address” error you saw. This is by design — the SQL Database firewall system and service endpoints are currently IPv4-only. Even if your client or network stack is IPv6-capable, the service endpoints (*.database.windows.net) resolve to IPv4 addresses only. That means all client-to-server communication happens over IPv4.
If your environment is IPv6-only, here are your main options:
- Use a dual-stack or NAT64 gateway – enable outbound IPv4 translation for traffic destined to
*.database.windows.net. This allows IPv6-only subnets to reach IPv4 services through NAT64 or DNS64.- This is the most common approach in hybrid IPv6 deployments.
- Use a private endpoint (recommended) – instead of relying on the public firewall, create a Private Endpoint for your SQL Database inside your dual-stack or IPv4-enabled VNet.
- This allows internal name resolution and connectivity over IPv4 through Azure backbone networking, bypassing the need to whitelist public IPs.
AFAIK, Microsoft has not announced any general availability or preview of IPv6 support for Azure SQL Database endpoints. Some Azure PaaS services (like Storage, App Service, and AKS) have rolled out IPv6 support, but SQL Database remains IPv4-only. There is no public roadmap or ETA, though IPv6 support is a commonly requested feature on the Azure Feedback Portal.
If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.
hth
Marcin