Forum Discussion
Local Network Gateway to Virtual Network Gateway - how does it know which vNet to use
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?
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:
- Section 3, Azure resources, step 2: this subnet glues the later VPN vnet to something "physical" (for want of a better-yet-shorter definition);
- Section 3, Azure resources, step 3: create the local gateway definition pointing to HQ (i.e. outbound routing specification);
- 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.