Can't RDP to VM in second hop VNet over S2S when connecting via Azure VPN (P2S)

Kane McConnell 1 Reputation point
2020-10-02T12:36:01.363+00:00

First, what I'm trying to accomplish. We have a central VNet in North Europe for corporate applications, databases, etc. However our on-premises locations are distributed globally. We'd like on-premises users to be able to connect via P2S through the nearest Azure region (i.e. J'burg, Singapore, Zurich, etc.) to reduce the length traveled over the Internet and get onto the Microsoft backbone as locally as possible. We prefer to use Basic VPN SKU due to the cost management of the number of regions involved globally.

Since the North Europe can only have one gateway, we can't use the simple hub-spoke peering set up. It would only work for one regional location. So, we've set up S2S VNet-to-VNet connections between all the regions and the North Europe. We've set up P2S in each regional VNet gateway for users to connect locally. Once connected to a VM in Zurich, for example, users can ping/RDP as expected into the North Europe resources. However, they can't do the same from their local machines over the P2S connection.

As a single example, we'll focus on Local > Zurich > North Europe. In the Zurich VNet, we've got a small Windows VM with IP forwarding enabled (on the nic and Windows firewall). We've played with UDRs, but nothing seems to let the P2S traverse the gateway to the S2S to be able to reach the North Europe resources.

North Europe (10.3.0.0/16)

  • NSG: default rules only
  • S2S: NEurope VNet-to-VNet to Zurich (Connected)
  • Gateway Subnet: 10.3.3.0/24
  • Windows VM 10.3.0.4
  • ICMP enabled
  • IP forwarding enabled on NIC and VM

Zurich (10.10.0.0/16)

  • NSG: default rules only
  • S2S: Zurich VNet-to-VNet to NEurope (Connected)
  • P2S: Address pool 172.16.10.0/24
  • routes.txt:
      ADD 10.10.0.0 MASK 255.255.0.0 default METRIC default IF default
      ADD 10.3.0.0 MASK 255.255.0.0 default METRIC default IF default
      ADD 172.16.10.0 MASK 255.255.255.0 default METRIC default IF default
    
  • Gateway Subnet: 10.10.3.0/24
  • Windows VM 10.10.5.4
    • ICMP enabled
    • IP forwarding enabled on NIC and VM

On-Premises (192.168.0.0/16)

  • P2S: Connected to Zurich
  • Can ping and RDP to Zurich VM 10.10.5.4
  • Can not ping or RDP to N Europe VM 10.3.0.4
  • P2S: Connected to N Europe
    • Can ping and RDP to to N Europe VM 10.3.0.4

So, the only functionality I'm missing is that I want the On-Premises machine to be able to ping and RDP to N Europe VM with an active P2S connection to Zurich. I've played around with route tables, tried using the Zurich VM as a simple NVA to forward IP traffic. For the life of me, I can't find a solution that will enable our Zurich P2S connections to reach the N Europe VNet.

Any guidance is greatly appreciated. I think I've broken Google. :)

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,528 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,427 questions
{count} votes

1 answer

Sort by: Most helpful
  1. SaiKishor-MSFT 17,231 Reputation points
    2020-10-04T00:36:56.04+00:00

    @Kane McConnell

    Thanks for the detailed explanation of the issue. I understand that you are unable to reach the North Europe VM with an active P2S via the Zurich-N.Europe S2SVPN. Please provide me with the following information to further understand the issue:

    • What kind of S2S VPN do you have between Zurich and North Europe (is it an Azure VPN)? Could you elaborate on your network setup further along with the IP address of the resources. If possible please attach a copy of the network diagram.
    • Does the VPN source and destination domains contain the P2S address space and the North Europe address space (i.e., the source domain for VPN at Zurich should include the 172.16.10/24 address space and the destination domain at the North Europe side should include the 172.16.10/24 address space).
    • Do you see this traffic reaching and response to this on the Windows VM i.e., 10.3.0.4 (doing a packet capture using Wireshark can shed more light on this).
    • If traffic is reaching the VM in N.Europe but VM does not respond to it, can your turn off Windows firewall temporarily and see if that makes any difference?

    Thank you!


Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.