Two VMs connected through VNet-to-VNet not pinging each other

Question

Again, I tried to create a VNet-to-VNet connection.

Briefly, I created

• Gateway Subnet at East US Region
• Gateway Subnet at West US Region
• Virtual Network Gateway for East US Region and
• Virtual Network Gateway for West US Region

Using Connection type VNet-to-VNet, I connected both Virtual Network Gateway from both sides.

I created connection between both Virtual Network Gateway.

The status of both connections says, Connected.

Windows Server Domain Controller is set up at East US and Windows 10 is installed at West US.

Windows 10 is unable to ping and join the Windows Server Domain Controller.

While joining the Domain Controller, the error message is

The issue is

I am able to connect both VMs which is at two different VNets using RDP with Public IP.

Both VMs’ virtual network gateways are also connected to each other through Connections.

I am able to connect one VM from another using RDP with Private IP. But I am not able to join Windows 10 VM to Windows Server 2016 Domain Controller.

I request please go through the link https://1drv.ms/u/s!Ail_S1qZOKPmlgBU5fLviInoisrx?e=ImrqpL and help me to fix the issue related to VNet-to-Vnet Connection so that Windows 10 VM from one VNet can join the Windows Server 2016 Domain Controller VM which is at another VNet.

I hope you'll consider it positively.

Regards TekQ

Answer 1

You might have to create routes, you are not using recommended private address space so routes are not created for you.

Azure automatically creates default routes for the following address prefixes: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16: Reserved for private use in RFC 1918. 100.64.0.0/10: Reserved in RFC 6598.

Check the effective routes to seen next hop for traffic in the peering address space.

https://docs.microsoft.com/en-us/azure/virtual-network/diagnose-network-routing-problem

Additional Information on VNet Routing

https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview

Answer 2

Instead of rely on Vnet Gateway and VPN S2S, you could as well using Vnet Peering between region.

https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview

Answer 3

I agree with the other answers. Global VNet Peering would remove the necessity of using a VPN GW, which greatly simplifies the environment and removes the monthly cost of hosting a pair of GWs. Assuming you need those GWs for other connections to VPN devices on-premises, then you can still use this design.

As Hannel pointed out, you're using public ranges for your private networks. That is also okay, but routing would be affected for VMs in those subnets if they attempted to go to actual public IPs in those ranges. Note that Hewlett Packard owns large parts of those ranges, so if your VM needed to get info from an HP website, you would have to create manual UDRs to route that traffic to Next Hop Internet.

So, please do check your Effective Routes on your NICs. You can check this from the NIC and also from Network Watcher. This should help you identify if another route is taking precedence or even if you have a route sending traffic to a virtual appliance.

Do make sure that you chose VNet-to-VNet when you set up your connection. If you chose IPSec, then you would need to have correctly configured your local network gateways.