Azure VNet portal rejects 64.0.0.0/2 with "private IP only" error, but accepts 64.0.0.0/3 and 64.0.0.0/4 (both public ranges). Why?

Bhavesh Shah 0 Reputation points
2026-10-06T11:57:32.2233333+00:00

While creating a Virtual Network in the Azure portal (Create virtual network → Address space tab), I noticed inconsistent validation for the same public (non-RFC 1918) IP space.

What I tried

| Address space | Range | Result |

|---|---|---|

| 64.0.0.0/2 | 64.0.0.0 – 127.255.255.255 | ❌ Error |

| 64.0.0.0/3 | 64.0.0.0 – 95.255.255.255 | ✅ Accepted |

| 64.0.0.0/4 | 64.0.0.0 – 79.255.255.255 | ✅ Accepted |

Error shown for /2:

The address range must be contained in one of the private IP address spaces: 192.168.0.0/16, 172.16.0.0/12, or 10.0.0.0/8.

Expected behavior

None of these ranges fall inside 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16, so I expected the same "private IP only" error for all three. Either all should be rejected, or all should be accepted.

Question

Why does the portal reject 64.0.0.0/2 with the private-range error, but accept 64.0.0.0/3 and 64.0.0.0/4, which are sub-ranges of the same public space? Is this intended validation behavior or a bug in the portal?User's image

User's image

User's image

Azure Virtual Network
Azure Virtual Network

An Azure networking service that is used to provision private networks and optionally to connect to on-premises datacenters.

0 comments
Answer accepted by question author
Salamat Shah 830 Reputation points MVP
2026-10-06T12:44:25.4566667+00:00

This is most likely a portal validation bug/inconsistency, not expected VNet behavior.

Azure VNets support any RFC1918 private range and also allow public IP address spaces you own, provided they don't overlap with reserved Azure ranges.

The portal rejects 64.0.0.0/2 with a "private IP only" message, but accepts the subsets 64.0.0.0/3 and 64.0.0.0/4.

Since all three ranges are public, the different validation result is inconsistent.

The likely cause is that the portal's client-side validation incorrectly flags very large prefixes such as /2, while smaller subsets bypass the check.

Recommendations:

  1. Test the same VNet creation using Azure CLI, ARM/Bicep, Terraform, or REST API.

If the API also rejects the range, it is a backend platform limitation.

If the API accepts it, then the issue is confirmed as an Azure Portal validation bug, and a support ticket should be raised.

Conclusion: The behavior is not logically consistent with IP addressing rules; it appears to be a validation issue specific to the Azure Portal rather than intentional design.

Was this answer helpful?

1 person found this answer helpful.

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.