VPN Gateway provisioned successfully but has no private IP address assigned

Hi @Re Group Partners - IT Department,

Thank you for reaching out on Microsoft Q&A forum.

I understand that you are not able to see private ip associated after successful creation of P2S VPN Gateway.

Could you please provide the following information so we can troubleshoot the issue further?

1. Have you verified that the GatewaySubnet is correctly configured and named "GatewaySubnet" in your virtual network?
2. Is your VPN Gateway SKU Standard or higher, or zone-redundant?
3. Have you configured the Point-to-Site VPN client address pool correctly, ensuring it does not overlap with your VNet or on-premises address spaces?
4. Are there any User Defined Routes (UDRs) or Network Security Group (NSG) rules on the GatewaySubnet that may block IP allocation or traffic?

Once we have this information, we’ll be able to better diagnose the issue.

Thanks,

Thanmayi

Here are the answers for the Microsoft rep:

---

1. Have you verified that the GatewaySubnet is correctly configured and named "GatewaySubnet" in your virtual network?

YES. Verified multiple times:

• Subnet name: GatewaySubnet (exact match, correct casing)
• Address space: 10.0.255.0/27 (32 IP addresses, ~27 usable)
• Provisioning state: Succeeded
• No subnet delegations
• No service endpoints

---

2. Is your VPN Gateway SKU Standard or higher, or zone-redundant?

YES. We have tested two zone-redundant SKUs:

• Initially deployed: VpnGw1AZ (zone-redundant, Generation 1)
• Currently deployed: VpnGw2AZ (zone-redundant, Generation 1)

Both SKUs show the same issue: Gateway provisions successfully (ProvisioningState: Succeeded) but PrivateIpAddress field remains null/empty.

Gateway configuration:

• Gateway Type: Vpn
• VPN Type: RouteBased
• Location: eastus2

---

3. Have you configured the Point-to-Site VPN client address pool correctly, ensuring it does not overlap with your VNet or on-premises address spaces?

YES. No overlaps exist:

VPN Client Address Pool:

• 172.16.0.0/24

VNet Address Space:

• 10.0.0.0/16

Subnets:

• GatewaySubnet: 10.0.255.0/27
• sql-subnet: 10.0.1.0/24

No on-premises networks - This is Point-to-Site VPN only (no Site-to-Site connections, no Local Network Gateway, no ExpressRoute).

There are no address space overlaps.

---

4. Are there any User Defined Routes (UDRs) or Network Security Group (NSG) rules on the GatewaySubnet that may block IP allocation or traffic?

NO. GatewaySubnet is clean:

• Route Table: None (verified via $gwSubnet.RouteTable = null)
• NSG: None (verified via $gwSubnet.NetworkSecurityGroup = null)
• Service Endpoints: None
• Delegations: None

The GatewaySubnet has no UDRs or NSG rules that could interfere with IP allocation.

---

Additional Context:

We have recreated the gateway 3 times with the same issue each time. The gateway always provisions successfully but never receives a private IP address in the IpConfigurations[0].PrivateIpAddress field, despite using Dynamic allocation method.

This appears to match the known issue with East US 2 backend capacity problems for VPN Gateway private IP assignment.

Resource Details:

• Subscription ID:
• Resource Group: stsqlimportmvp-rg
• Gateway Name: stsqlimportmvp-vpngw
• Resource ID:

---

Copy that entire response and paste it to the Microsoft rep! 📋Here are the answers for the Microsoft rep:

---

1. Have you verified that the GatewaySubnet is correctly configured and named "GatewaySubnet" in your virtual network?

YES. Verified multiple times:

• Subnet name: GatewaySubnet (exact match, correct casing)
• Address space: 10.0.255.0/27 (32 IP addresses, ~27 usable)
• Provisioning state: Succeeded
• No subnet delegations
• No service endpoints

---

2. Is your VPN Gateway SKU Standard or higher, or zone-redundant?

YES. We have tested two zone-redundant SKUs:

• Initially deployed: VpnGw1AZ (zone-redundant, Generation 1)
• Currently deployed: VpnGw2AZ (zone-redundant, Generation 1)

Both SKUs show the same issue: Gateway provisions successfully (ProvisioningState: Succeeded) but PrivateIpAddress field remains null/empty.

Gateway configuration:

• Gateway Type: Vpn
• VPN Type: RouteBased
• Location: eastus2

---

3. Have you configured the Point-to-Site VPN client address pool correctly, ensuring it does not overlap with your VNet or on-premises address spaces?

YES. No overlaps exist:

VPN Client Address Pool:

• 172.16.0.0/24

VNet Address Space:

• 10.0.0.0/16

Subnets:

• GatewaySubnet: 10.0.255.0/27
• sql-subnet: 10.0.1.0/24

No on-premises networks - This is Point-to-Site VPN only (no Site-to-Site connections, no Local Network Gateway, no ExpressRoute).

There are no address space overlaps.

---

4. Are there any User Defined Routes (UDRs) or Network Security Group (NSG) rules on the GatewaySubnet that may block IP allocation or traffic?

NO. GatewaySubnet is clean:

• Route Table: None (verified via $gwSubnet.RouteTable = null)
• NSG: None (verified via $gwSubnet.NetworkSecurityGroup = null)
• Service Endpoints: None
• Delegations: None

The GatewaySubnet has no UDRs or NSG rules that could interfere with IP allocation.

---

Additional Context:

We have recreated the gateway 3 times with the same issue each time. The gateway always provisions successfully but never receives a private IP address in the IpConfigurations[0].PrivateIpAddress field, despite using Dynamic allocation method.

This appears to match the known issue with East US 2 backend capacity problems for VPN Gateway private IP assignment.

Resource Details:

• Subscription ID:
• Resource Group: stsqlimportmvp-rg
• Gateway Name: stsqlimportmvp-vpngw
• Resource ID:

---

Copy that entire response and paste it to the Microsoft rep! 📋