Azure VPN Gateway Indonesia Region

The simultaneous loss of the second active-active instance across all sites, combined with HTTP 500 errors from both the portal and PowerShell, should be investigated first as a gateway-instance or regional service problem—not resolved by changing every site’s IPsec policy solely because Resource Health labels it “Customer Initiated.”

1. Check subscription-specific Azure incidents

Open Azure portal → Service Health:

1. Select Service issues and filter for:
   • The affected subscription
   • Indonesia Central
   • VPN Gateway
2. Select Health history and review events beginning around October 27, 2026, 02:06 GMT+7.
3. Open Resource health and inspect the VPN gateway itself, not only its connection resources.

Service Health contains subscription- and region-specific incidents that might not appear on the global Azure Status page; Resource Health reports the history of an individual resource.^1^ ^2^

No public Azure Status incident specifically confirms an Indonesia Central VPN Gateway outage on that date. A subscription-specific incident can therefore still be present.

2. Test the second gateway instance directly

For an active-active gateway, test the health endpoint associated with its second public IP:

https://<second-gateway-public-IP>:8083/healthprobe

A certificate warning is expected.

• Response returned: The instance is responding; continue with IPsec/IKE diagnostics.
• No response: The gateway instance might be unhealthy, although an NSG on GatewaySubnet can also prevent the probe from succeeding.^3^

Also check the gateway’s provisioning state independently of the failing BGP operation:

az network vnet-gateway show \
  --name "<gateway-name>" \
  --resource-group "<resource-group>" \
  --query "{state:provisioningState,activeActive:activeActive,sku:sku.name}" \
  --output json

If the state is persistently Failed or Updating, the gateway cannot reliably negotiate tunnels; capture evidence and proceed to support or a controlled reset.^4^

3. Preserve diagnostic evidence before resetting

If diagnostic settings already send VPN Gateway logs to Log Analytics, correlate the affected instance, BGP, and configuration events:

AzureDiagnostics
| where Category in
    ("GatewayDiagnosticLog", "TunnelDiagnosticLog", "RouteDiagnosticLog")
| where TimeGenerated > datetime(2026-10-26T18:30:00Z)
| project TimeGenerated, Category, OperationName,
          instance_s, remoteIP_s, Message
| order by TimeGenerated asc

Look for:

• All failed tunnels reporting the same instance_s.
• TunnelDisconnected events on the second instance.
• BgpDisconnectedEvent at the same time.
• HostMaintenanceEvent or GatewayTenantPrimaryChanged.
• SetGatewayConfiguration or SetConnectionConfiguration.

A disconnect on one instance followed by reconnection on another is consistent with gateway failover or maintenance. GatewayDiagnosticLog also shows whether a gateway or connection configuration was actually modified, which helps distinguish a real customer configuration change from the Resource Health classification.^5^

BGP depends on the underlying IPsec tunnel, so a failed second-instance tunnel will also prevent that instance’s BGP sessions from connecting.^6^

4. Reset only after collecting evidence

If there is no active Service Health incident, the second health probe fails, and no configuration change explains the event, reset the affected instance during a maintenance window.

Risk: A reset reboots a gateway instance, briefly interrupts connectivity, and can reduce the evidence available for root-cause analysis.

For an active-active gateway, PowerShell or CLI can target an instance by its public VIP:

az network vnet-gateway reset \
  --name "<gateway-name>" \
  --resource-group "<resource-group>" \
  --gateway-vip "<affected-instance-public-IP>"

Azure documents that active-active instances can be reset separately using their VIPs and that the gateway configuration and public IP are retained.^7^

5. Escalate if the instance or API remains unavailable

Open an Azure support request if:

• Service Health has no matching incident;
• the second-instance health probe does not respond;
• BGP status continues returning HTTP 500;
• all connections through the same instance remain unavailable; or
• reset does not restore the instance.

Include the gateway resource ID, affected second public IP, timestamps in UTC, PowerShell correlation/request details, Resource Health event, and exported diagnostic logs. The cross-site concentration on one instance and the management API failure are particularly important.

Only pursue an IPsec/IKE policy correction if IKEDiagnosticLog shows concrete messages such as Policy Mismatch, Policy match error, or NO_PROPOSAL_CHOSEN; those indicate that encryption, DH group, hashing, or PFS settings must be aligned.^4^

References

1. Azure Service Health FAQ
2. Azure Service Health portal
3. Troubleshoot an Azure site-to-site VPN connection that can't connect and stops working
4. Troubleshoot a Site-to-Site or Point-to-Site VPN tunnel that won't connect in Azure VPN Gateway
5. Troubleshoot Azure VPN Gateway using diagnostic logs
6. Troubleshoot BGP issues for Azure VPN Gateway
7. Reset a VPN gateway or a connection