Nov 10 2021 04:00 PM
Nov 10 2021 04:00 PM
Was trying out the example from Microsoft Documentation:
While overall the concept is straightforward, I am unable to comprehend how the Virtual Network Gateway knows which vNet to associate with.
az network vnet create \ --resource-group [sandbox resource group name] \ --name VNG-Azure-VNet-1 \ --subnet-name GatewaySubnet
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?
Nov 10 2021 05:00 PM
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.
Nov 10 2021 06:51 PM
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?
Nov 10 2021 07:19 PM
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:
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.