Local Network Gateway to Virtual Network Gateway - how does it know which vNet to use

[DensuShiv]

Was trying out the example from Microsoft Documentation: 

Exercise - Create a site-to-site VPN gateway by using Azure CLI commands - Learn | Microsoft Docs

While overall the concept is straightforward, I am unable to comprehend how the Virtual Network Gateway knows which vNet to associate with. 

Creating VNG-Azure-VNet-1

az network vnet create \ --resource-group [sandbox resource group name] \ --name VNG-Azure-VNet-1 \ --subnet-name GatewaySubnet

Creating vnet-gateway

az network vnet-gateway create \ --resource-group [sandbox resource group name] \ --name VNG-Azure-VNet-1 \ --public-ip-addresses PIP-VNG-Azure-VNet-1 \ --vnet VNG-Azure-VNet-1 \ --gateway-type Vpn \ --vpn-type RouteBased \ --sku VpnGw1 \ --no-wait

In both the places there is no reference to either the Azure vNet or the simulated on-premise network. Seems something very simple is hidden from the view. How does the vnet-gateway know how to connect to the actual vNet?

[#2]

@DensuShiv 

So, conceptually, the commands you've dropped in above relate to defining the virtual - or VPN - network. At this early stage, you haven't reached the point of connecting it to anything.

Going back to basics, before you can connect two VPN networks, you need to actually define what those networks look like - which is what these commands are achieving. After these commands are done, you've defined what the VPN network looks like but nothing is connected - that comes later in section 4 of the exercise.

Technically, in having now defined the VPN network, you could walk away and it'd happily sit there doing nothing, waiting for something to come along on the other end and connect.

In short, section 3 had you setting up the IP-level routing to establish connectivity between Azure and HQ. Section 4 sees you then layer the VPN on top of that basic IP connectivity established in section 3.

The "joining" of the VPN network to the "physical" network is achieved through section 4, step 2 of "Create the Azure-side VPN gateway", where you're binding the VPN network to the "GatewaySubnet" subnet defined earlier in section 3.

It's all much the same as the steps you have to do on any other kind of VPN server. You just have to to a bit more in this lab as you aren't coming from the position of already having the physical layer established. But the concepts of specifying the VPN specifics (IP ranges, gateway addresses/interface exposed on, routes, etc.) are the same.

[#3]

@LainRobertson

Thanks for your response. The place I am a bit lost is the binding part. None of the above commands point to the VPN vNet created in earlier steps - Azure-VNet-1.

During the creation of LNG-HQ-Network or VNG-Azure-VNet-1 or the connection Azure-VNet-1-To-HQ-Network using the above commands there is nowhere we are specifying Azure-VNet-1 as the vnet to connect to. Without specifying this vnet in these commands, how does the binding happen?

 

[#4]

@DensuShiv 

Yeah, I think the chronology could be a little better, but looking in the direction of Azure-to-HQ it's essentially it's a combination of:

1. Section 3, Azure resources, step 2: this subnet glues the later VPN vnet to something "physical" (for want of a better-yet-shorter definition);
2. Section 3, Azure resources, step 3: create the local gateway definition pointing to HQ (i.e. outbound routing specification);
3. Section 4, Create Azure VPN gateway, step 2: this is what glues the currently free-floating VPN vnet to a "physical" routing component - created in point 1 above.

And then you've got the same in reverse for HQ, but that's not as interesting as it's just a lab substitute for real world HQ-side physical configuration.

Using the picture from the start of section 3, the line dropping down from PIP-VNG-Azure-VNet-1 to GatewaySubnet is what's giving the Azure-side VPN vnet its connectivity to HQ.