Hello, and welcome back. In this demonstration here, what we're going to do is deploy a site to site VPN. We are going to connect the MyVnet virtual network that we created earlier to an on-prem network. What we're going to do here is deploy a virtual network gateway, a local gateway, and then we're going to create a VPN connection that connects our virtual network gateway, which represents MyVnet, and we're going to connect that to the local gateway, which is going to represent our VPN device on the on-prem network.

Now, what we need to do before we get started is deploy a gateway subnet on our MyVnet virtual network. Now, this gateway subnet is going to host the underlying VMs that Azure spins up to facilitate the VPN connection. These are VMs that we can't see, but trust me, they're there. To create our gateway subnet, what we do from our MyVnet virtual network here is select subnets. And then we can see, we have my subnet that was provisioned earlier. And then what we're going to do is click on gateway subnet. And what this does is allow us to create this special subnet that the VPN will use to establish connectivity between MyVnet and the on-prem network.

What we need to do here is specify an address range for our gateway subnet. And if you notice, you can't even change the name of gateway subnet. This name gateway subnet is important because Azure looks at that and says, oh, okay, this must be the subnet we need to use for this VPN gateway that we're setting up.

Now, what we're going to do here is change this CIDR block. Right now the default address range for our gateway subnet is one 192.168.00/24. I don't need a gateway subnet that encompasses most of my address space. So what we'll do is we'll make this a .2.0 and we'll make it a /28. So what I've just done here is I took a very small piece of my overall address space of 192.168.00, and carved it out for my gateway subnet.

Since only a few resources are deployed to this gateway subnet by Azure, we don't need a whole lot of network addresses available. To be honest, even 11 here plus the five reserved is probably too many. We could probably even get away with a /29 here, but we'll go ahead and leave it at 28, just to make sure.

We don't need to configure a gateway or any network security groups, routing tables... This stuff all is left at its default setting when creating a gateway subnet, so we'll go ahead and click okay here. So we now have our gateway subnet deployed and what we'll do now is create the virtual network gateway for our VPN. Now, this process is going to take 45 minutes to complete, so what I'm going to do is just walk you through the process of beginning the deployment, and then we'll come back when the deployment is finished.

So let's go ahead and hit the hamburger here and create a resource. And what we'll do here is search for virtual network gateway. And we have it here and we'll go ahead and create it. As you can see on your screen, there's quite a bit of information we need to supply here, although a lot of these are defaults.

So what we'll do here is we'll deploy into the lab subscription. And what we'll do here is we'll call it my gateway. And we'll deploy into Central US, which is where I typically install stuff. Now we have two choices of gateway here, either a VPN or ExpressRoute. We're not deploying an ExpressRoute, so VPN is the default and we'll leave it there. And the same thing with VPN type, we can deploy a route-based VPN or a policy-based VPN.

If we hover over the icon here for type, we can see that the VPN we choose is going to depend on the make and model of the VPN device we're trying to connect to. It's also gonna be driven by the kind of VPN connection we want to create. As you can see in this box, what we wanna do is choose the route based option if we're going to create a point of site inter virtual network, or if we're going to create multiple sites to site connections.

We can see that policy-based gateways only support IK V1. If we need IK V2, we need to go route based. For this demonstration here, we're going to go route based. And then here we have the SKU. If we select the dropdown we can see all of the different options we have. We're going to do basic here. But if I hover over SKU here, we can see that route-based VPNs are offered in three different SKUs, basic, standard, and high performance.

If we're going to create a VPN that co-exists with ExpressRoute, we can see here that we need to choose standard or high performance. If we're going to go active, active, we need to select high performance. This is a basic demonstration. We're not doing anything crazy so we can get away with a basic generation one gateway.

If we hover over the icon here for virtual network, we can see that the virtual network that we specify in this dropdown is the virtual network that we're going to configure so that it can send and receive traffic on this gateway. So what we'll do here is we will select MyVnet and we can see here that it found the gateway subnet automatically.

Now, since the on-prem device needs to be able to communicate with this gateway over the internet, this gateway needs to have a public IP address. We can either use an existing public IP or create a new one. I don't have an existing public IP, so we'll let this process create a new one and we'll call the public IP gateway IP. The public IP address SKU is going to match the SKU of the gateway we're setting up. We can leave these last two options disabled since we're not doing any kind of active, active stuff, and we're not replicating using BGP.

Since we're not going to tag anything, we can go ahead and review and create here. And what Azure has done is validated my configurations. So we are deploying a gateway called my gateway into the Vnet demo's resource group within my lab subscription. We're deploying into Central US and the SKU for this gateway is a basic generation one. This gateway is going to allow traffic to and from the MyVnet network, and the gateway subnet is the one that we defined earlier.

We're deploying a route-based VPN type using a VPN type gateway. We've disabled the active active mode in BGP, and we've assigned a new IP called gateway IP to our virtual network gateway. Once this virtual network gateway creation process completes, Azure will assign a dynamic public IP address to it. And we will need that to configure our VPN device on-prem, which by the way, I am not going to cover in this demonstration. And I'm not going to cover that because every VPN device is different.

What I'm doing here in this demonstration is showing you all of the pieces that you need to do within the Azure portal to make Azure talk to an on-prem VPN device. The steps you need to take to configure your given VPN device in your own environment will be drastically different depending on the device itself. So let's go ahead and create our gateway here, and we can see that the deployment is underway.

So this really is going to take about 40 to 45 minutes to complete, so I'm going to let this run, and then when it's completed, we'll come back and I'll show you what the next steps are, and then we'll take it from there.