Site-to-site VPN connection fails between two hub vnets in different region

Question

Site-to-site VPN connection fails between two hub vnets in different region

Rajesh Swarnkar 1,116

Hi, I am trying to implement this sample architecture to explore the Route server beahviour . But the S2S VPN connection keeps failing.

User's image

Architecture: User's image

On researching I got ot know that it is “old” way to peer networks. But now curious to know why the S2S Connection fails. Here is my Connection sesstings:

User's image

Venkatesan S 6,695 Reputation points Microsoft External Staff Moderator

2026-04-10T03:31:37.44+00:00

Hi Rajesh Swarnkar,
We haven’t heard back from you regarding our last response and wanted to check if you had the opportunity to review our previous post.

Please “up-vote” if the information helped you. This will help us and others in the community as well.
Praveen Bandaru 11,310 Reputation points Microsoft External Staff Moderator

2026-04-15T19:26:02.6166667+00:00
Hello **Rajesh Swarnkar
**You’ve set up two Azure VNets as “on-premises” sites and connected them using a Site-to-Site VPN between their gateways. While this can work, there are some important points to consider. For direct VNet-to-VNet (cross-region) connectivity, Azure provides a simpler “VNet-to-VNet” connection model. Here are some things to check:

You may have selected the wrong connection type

With the “Site-to-Site (IPsec)” method, you must manually configure each Local Network Gateway with the other gateway’s public IP and correct address prefixes.

Check your Local Network Gateway settings

Ensure the peer VPN gateway’s public IP is accurate (not a private IP or Route Server IP).

The “Address space” under Local network gateway → Address space should match the remote VNet’s CIDR exactly.

Make sure the shared key, IKE version, and IPsec policy are consistent on both sides.

Verify you’re using route-based gateways

Cross-region S2S connections require a route-based SKU. Avoid policy-based traffic selectors.

Use Azure Network Watcher VPN diagnostics

Enable VPN diagnostics and packet capture in the Azure portal for each gateway to identify if Phase-1 or Phase-2 is failing.

And check the default IPsec parameters configured properly or not check the below document for more understanding:

Default IPsec/IKE parameters

Check the document for more understanding: https://learn.microsoft.com/en-us/troubleshoot/azure/vpn-gateway/vpn-gateway-troubleshoot-site-to-site-cannot-connect

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "upvote" where the information provided will help you, this can be beneficial to other members of the community.

2 answers

Your answer

Venkatesan S 6,695 Reputation points Microsoft External Staff Moderator

2026-04-10T03:31:37.44+00:00

Hi Rajesh Swarnkar,
We haven’t heard back from you regarding our last response and wanted to check if you had the opportunity to review our previous post.

Please “up-vote” if the information helped you. This will help us and others in the community as well.
Praveen Bandaru 11,310 Reputation points Microsoft External Staff Moderator

2026-04-15T19:26:02.6166667+00:00

Hello **Rajesh Swarnkar
**You’ve set up two Azure VNets as “on-premises” sites and connected them using a Site-to-Site VPN between their gateways. While this can work, there are some important points to consider. For direct VNet-to-VNet (cross-region) connectivity, Azure provides a simpler “VNet-to-VNet” connection model. Here are some things to check:

You may have selected the wrong connection type

With the “Site-to-Site (IPsec)” method, you must manually configure each Local Network Gateway with the other gateway’s public IP and correct address prefixes.

Check your Local Network Gateway settings

Ensure the peer VPN gateway’s public IP is accurate (not a private IP or Route Server IP).

The “Address space” under Local network gateway → Address space should match the remote VNet’s CIDR exactly.

Make sure the shared key, IKE version, and IPsec policy are consistent on both sides.

Verify you’re using route-based gateways

Cross-region S2S connections require a route-based SKU. Avoid policy-based traffic selectors.

Use Azure Network Watcher VPN diagnostics

Enable VPN diagnostics and packet capture in the Azure portal for each gateway to identify if Phase-1 or Phase-2 is failing.

And check the default IPsec parameters configured properly or not check the below document for more understanding:

Default IPsec/IKE parameters

Check the document for more understanding: https://learn.microsoft.com/en-us/troubleshoot/azure/vpn-gateway/vpn-gateway-troubleshoot-site-to-site-cannot-connect

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "upvote" where the information provided will help you, this can be beneficial to other members of the community.

Answer 1

Hi Rajesh Swarnkar,

Thanks for reaching out in Microsoft Q&A forum,

Your S2S setup between two Azure VPN Gateways won't work it's using the wrong connection pattern. Here's the deal in plain English:

You're building this:

VPN Gateway (centralindia) > Local Network Gateway > Connection > VPN Gateway (southindia)

Local Network Gateways tell Azure, "this is an on-premises VPN device." But you're pointing them at another Azure VPN Gateway. Azure's control plane goes, "Wait, where's the customer VPN appliance?" and the IPsec handshake fails silently hence "Unknown."

Your Settings Are Fine, Architecture Isn't

Your connection config looks good:

IKEv2 enabled
Default mode
BGP enabled (perfect for Route Server testing)
Standard PSK

This isn't a config tweak issue; it's the wrong topology.

Option 1: VNet-to-VNet Connections (Keeps IPsec)

Delete your current connections. Recreate properly:

1. vpng-centralindia > Connections > +Add > "VNet-to-VNet"     - Target: vpng-southindia directly (no LNG)
2. vpng-southindia > Connections > +Add > "VNet-to-VNet"    - Target: vpng-centralindia directly (no LNG)

Option 2: Global VNet Peering (Recommended for Route Server)

Simplest fix, no IPsec, pure Azure backbone:

1. Delete both failing connections + both Local Network Gateways
2. Central VNet → Peerings → +Add → South VNet
   - Allow gateway transit: YES
3. South VNet → Peerings → +Add → Central VNet
   - Use remote gateways: YES

Route Server shines with peering:

Central Route Server learns VPN Gateway routes → propagates to South via peering
South Route Server learns Central routes → full mesh automatically
No tunnel state to manage

BGP works end-to-end

  On-Prem > Central VPN > Route Server > Peering > South Route Server > South VPN > On-Prem

Go with peering since you're testing Route Server:

1. Delete connect-central-to-south2 & connect-south-to-central2 
2. Delete Ing-in-centralindia & Ing-in-southindia (LNGs) 
3. Create bidirectional Global VNet Peering with gateway transit 
4. Watch Route Servers auto-propagate routes

Official Docs:

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

The site-to-site VPN between the two hub VNets fails for the same reasons any Azure S2S tunnel fails: one or more of the core parameters on the two sides don’t match, or the gateway path is being blocked. Use the standard S2S troubleshooting flow to find the mismatch.

Follow these checks end to end on both VPN gateways and both local network gateways:

Reset both VPN gateways and tunnels
First reset each Azure VPN gateway, then reset the tunnel from the opposite side. This clears stale state and is the recommended first step when a previously working or newly created tunnel won’t connect.
Verify the VPN device type and configuration
In this scenario, each Azure VPN gateway is effectively acting as the “device” for the other side. Ensure both gateways are route‑based and support IKEv2, and that no custom IPsec/IKE policy is applied on one side but not the other.
Confirm the shared key is identical on both connections
The pre‑shared key must match exactly on the two connections:
- In the portal, open each connection and check the Authentication / Shared key.
- Or use PowerShell:
```
     Get-AzVirtualNetworkGatewayConnectionSharedKey -Name <ConnectionName> -ResourceGroupName <RG>
```
If they differ, update one side so both keys are identical.
Verify VPN peer IPs and Local Network Gateway definitions
For each local network gateway:
- The IP address must be the public IP of the remote VPN gateway.
- The address spaces must exactly match the remote VNet address space(s).
On each on‑premises definition (here, the opposite Azure gateway):
- Ensure the remote gateway IP configured is the public IP of the other Azure VPN gateway.
  Any mismatch here will keep the tunnel in Unknown / Not connected state.
Check for UDRs or NSGs on the gateway subnet
On each hub VNet, inspect the gateway subnet:
- Remove any user‑defined routes or NSGs from the gateway subnet and test again.
- If the tunnel comes up, re‑add UDR/NSG rules carefully so they don’t block IPsec or health‑probe traffic.
Validate that the on‑premises (remote) IP isn’t inside the local network definition
Ensure the public IP of each VPN gateway is not included in the address prefixes of the opposite local network gateway. If it is, sporadic or failed connections can occur.
Use the gateway health probe to confirm gateway health
For each VPN gateway public IP, browse:
- https://<GatewayPublicIP>:8081/healthprobe
  For active/active, also check :8083.
  If there is no response, the gateway may be unhealthy or blocked by an NSG on the gateway subnet.
Check IPsec/IKE options such as Perfect Forward Secrecy
If custom IPsec/IKE policies are used and Perfect Forward Secrecy (PFS) is enabled on one side but not the other, the tunnel can fail. Ensure both sides use matching IPsec/IKE parameters, or revert to the default policy on both connections.

Once these parameters (peer IPs, address spaces, shared key, IPsec/IKE settings) are symmetric and any blocking NSGs/UDRs are removed from the gateway subnets, the S2S VPN between the two hub VNets should move from Unknown/Not connected to Connected.

References:

Share via

Site-to-site VPN connection fails between two hub vnets in different region

2 answers

Your answer