Problem With Computers Accessing Azure VM's Across IPSecVPN and Vice Versa

Jim Aloye 1 Reputation point
2022-01-29T07:30:44.19+00:00

We have an IPSec Site To Site Tunnel Connecting our Azure Virtual Network to another Cloud and the IPSec Site to Site VPN is live, lit up as connected, and according to Azure and the Cloud Object on the other side, the IPSec VPN is live/connected/active.

Here are the details:

We have an Azure Resource Group named vm-rg
Inside vm-rg there is a virtual network named vm-rg-vnet
On vm-rg-vnet, sit two Azure virtual machines.
Each azure virtual machine has 1 NIC.
inside of subnet 10.x.y.0/24 on VMNet (10.x.y.0/16)
VM 1 NIC 1 is 10.x.y.v
VM 2 NIC 1 is 10.x.y.w

There is also a virtual network gateway on vm-rg-vnet
The GatewaySubnet contains a Site-to-site (IPsec) VPN with the following info:
GatewaySubnet (10.x.q.0/27)
VirtualNetworkGatewayIP (a.b.c.d)
Also, inside of vm-rg-vnet is a local network gateway.
The Azure Local NetWork Gateway contains the following info:
IP Address: a.b.c.d
Address space: 10.j.y.0/16

Given the above information, the problem we have is none of our computers that live on the 10.j.y.0/16 network can communicate with the Azure side of the VPN on the 10.x.y.0/24 subnet of the 10.x.y.0/16 network.

On the Azure side, Server 1 has IP 10.x.y.v . Server 2 has IP 10.x.y.w

Likewise, the servers that live on 10.x.y.0/16 in the 10.x.y.0/24 subnet cannot ping or communicate with the computer that live at 10.j.s.4 or any of our other devices on the 10.j.y.0/16 network.

have any-to-any firewall config setup, so the problem is not a firewall, it must be a networking issue of some kind.
The computers that live on the 10.x.y.0/16 network can also not reach or ping the VirtualNetworkGatewayIP (aa.bb.cc.dd) on the opposite side.

The azure computers that live at 10.x.y.0/24 subnet in the 10.x.y.0/16 network cannot ping the other side of the vpn which is zz.rr.qq.pp

The end of the VPN Link that begins in P81 with Perimeter81-Gateway-IP (zz.rr.qq.pp) and ends in Azure with VirtualNetworkGatewayIP(aa.bb.cc.dd) is showing that it is Live and fully Connected.

Likewise, the end of the VPN Link that begins in Azure with VirtualNetworkGatewayIP (aa.bb.cc.dd) and goes to Perimeter81-Gateway-IP (zz.rr.qq.pp) is showing that it is Live and fully Connected.

Nothing is able to communicate across this VPN so the VPN is currently useless even though the vpn is showing on both sides that it is up and connected.

What needs to happen so the computers and servers at 10.x.y.0/16 can talk to the machines at 10.j.y./0/16 and vice versa?

Any help would be greatly appreciated.

Azure VPN Gateway
Azure VPN Gateway
An Azure service that enables the connection of on-premises networks to Azure through site-to-site virtual private networks.
1,365 questions
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.
2,129 questions
{count} votes

3 answers

Sort by: Most helpful
  1. Jim Aloye 1 Reputation point
    2022-01-29T10:58:04.057+00:00

    Does anything specific look like it is missing?

    I cannot ping to either end of the vpn gateway.

    What am I missing??


  2. Jim Aloye 1 Reputation point
    2022-01-29T18:35:28.93+00:00

    Step 7 checks out result is below.

    <string>
    Primary Instance: GatewayTenantWorker_IN_0 GatewayTenantVersion: 21.5.100.13 OSVersion: Windows Server 2019 Datacenter
    </string>

    The other steps line up also. No firewalls are blocking anything.

    computers cannot reach each other across the vpn, but the vpn is up live and light is green.

    Is there some kind of route that is missing, that I need to enter?

    What would that be? I suspect there is something being missed. I need to understand what is missing exactly.

    0 comments No comments

  3. Jim Aloye 1 Reputation point
    2022-01-30T01:54:48.027+00:00

    Found the problem.

    The IPSec Tunnel from the external cloud was using 10.x.q.0/27 as the address space on the other end of the VPN.

    That was incorrect. The address space on the other end should be the VMNet (10.x.y.0/16) address space.

    problem resolved.