Forum Discussion

DensuShiv's avatar
DensuShiv
Copper Contributor
Nov 11, 2021

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

  Was trying out the example from Microsoft Documentation:    https://docs.microsoft.com/en-us/learn/modules/connect-on-premises-network-with-vpn-gateway/4-exercise-create-a-site-to-site-vpn-gatew...
DensuShiv's avatar
DensuShiv
Copper Contributor
Nov 11, 2021

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?

 

 

LainRobertson's avatar
LainRobertson
Silver Contributor
Nov 11, 2021

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.

Resources