Hello and welcome back to Cyber Aires. Microsoft Azure Administrator A Z 103 Course, This is Episode 41 Vignette Definite connections and I'm your instructor, Will Carlson.
In today's episode, we're gonna understand the steps required to implement one of the V Net to V Net connections here in Azure. We're going to discuss some of the differences, and I'll point you to the documentation to get further information about the differences between the gateway skews offered to you.
And then we're gonna walk through how we could configure that up for a site decide or ravine et tu vy net connection here within azure as well.
But first of all, what are the steps required to implement a Veena TV net connection in azure? And this is gonna be something I believe you should know relatively well. For the ese 103 exam. At least be familiar with the steps. I think this is really great testable information. And to get started, the first thing you have to do
is create the virtual networks and the sub nets that you're going to be using to connect
to or together in our case for a veena TV net connection.
The next thing you're gonna have to do is create the gateway sub net. Now, if you're doing this into your on premise environment, you're gonna have to have a sub net a gateway sub net on the inside of azure. And you're gonna have to have the sub nets beyond that that you ultimately want to connect with and what's gonna live in that gateway sub net is the gateway itself. So we'll do Cem
tweaking things to make that gateway sub net as efficient as possible
when we get into portal. But do know that you're gonna have a gateway sub net for the VP and Gateway to live in, and that's gonna connect through to your virtual network sub net of interest.
The next thing we have to do is actually create the VP in Gateway.
Now, Portal makes us pretty interesting because, as it does with many other things, it loves a couple of these steps, particularly steps two and three altogether in one wizard to simplify things for us.
Once we have all those things taken care of,
we have to actually create the local network gateway, and this is gonna be in the instance of doing a azure connection to a site connection on your on prim network. So a site to site VPN connection.
Once we have the local side all set up, we'll need to configure the actual on prim device. So our edge router or edge device are internal VP and Gateway,
and then we're gonna go ahead and establish the VP in connection between those two locations. So
these series of steps are really indicate how you set up a site to site B p in connection with an azure, and that's gonna be connecting azure to your on premise environment. You get the azure side, all set up sub nets of interest, the VP and Gateway sub net. You deploy the gateway, and then you essentially do the same thing in your on premise environment.
You have the sub nets likely already set up.
You'll configure your firewall on that end to connect into Azure, and then you're finally ready to make the connection together.
Now we're gonna go through here in portal setting this up between two virtual networks within portal, and you may be wondering why in the world we would want to do that when we have options presented to us such a zvi net peering and it's all one step. It is definitely more simple being appearing than Wien et tu vy net
However, there are some advantages to both. Really, it just depends on your use case.
The first difference here is going to be on the way that they're priced and V Net peering is going to be priced based on inbound and outbound data transfer. It's going to depend on a number of things here for global Veena peering. But being appearing within the same region is relatively straightforward.
You're gonna pay a penny per gigabyte in and out of the veena appear
global bean appearing. You can see the pricing here is gonna be dependent upon which zone you're in and you can find information about those owns in the Microsoft documentation. But this is going to be a very, very variable pricing plan for Veena appearing Wien appearing also is not encrypted in anyway. So
you are staying in the traffic is maintained on the azure backbone network. It doesn't traverse the public Internet,
but it is not encrypted currently.
So if you want to encrypt or have a little bit of a different pricing model. You can use a virtual network gateway or a VPN gateway, and
they're gonna be price based on the compute for the virtual, the VP and Gateway itself.
And based on bandwidth,
so you could have a basic skew here. It's gonna be four. Since an hour when that gateway is running and you get 100 megabytes of connection,
you can have up to 10 site to site tunnels and again these air going to be azure to EJ appliance type connections.
Or you gonna have pointed to cite tunnels up to 128 on the basics. Q and Point to cite tunnels are going to be those that are azure connecting to an end point. Think a a mobile laptop client can still connect in tow azure, but they would use a point to cite tunnel.
And as you step up in the skews, the price goes up, but so does the functionality. You get more tunnels allowed to you, and you also get more bandwidth. Now there is no inbound transfer cost,
but there are outbound transfer costs for VP and gateways, so there is a variable component here in some instances, so you'll need to pay attention to this as well. Toe size, the right solution for your deployment. But remember,
VP and Gateway is encrypted. This is essentially setting up an I P sec VP in between azure
and whatever other end point you choose
to get started in the V. P in the V net TV net set up. I'm gonna come up here to create a resource,
have been virtual here, and I can see virtual network *** way. But we're gonna go ahead and select create here on the virtual network Gateway.
We're gonna leave this in my free trial subscription as usual.
I'm going to go ahead and leave this in my free trial subscription. As usual, I get to name this year.
I'm gonna put this in the region that I know I have those sub nets already created him,
and I can see I have some gateway types. One is VP and which is the one we'll be talking about today. But know that we talked about express route in another video, and that should make some more sense there as well. Once you've watched the Express route video.
I also have some options says to the VPN type Now, typically, you'll be using route based. But if you have more sophisticated endpoint devices that can do policy based routing, you can go ahead and configure that policy based is well. But suffice it to say that Route based is going to be based on
this particular sub net. If you're trying to get here, then traverse this VP and connective ITI. It's not super intelligent. It's doesn't have any idea about who's singing, the traffic, where it's coming from, or any policies set on the azure side or your on premise side.
It's just gonna be based on the I. P address of the destination.
So we're gonna leave that his route based here is where we can select our skews, and I recommend again going through some of those some of the documentation and looking through what the's skews our to get a good understanding of some of the differences
you'll also see here these ese skews and these air going to be VP and gateways deployed in multiple availability zones. It's gonna be the same concept as anything else deployed in availability zones gonna help us increase our reliability and are up time. But we're gonna go ahead and select basic for now,
and then I'll come down and select my virtual network on the inside here in Azure and you'll see that it's going to create a sub net for me. And this is going to be the gateway sub net. Now, remember, in the steps that we just talked about in the previous slide, I mentioned that portal makes
combines a couple of these steps and this is what I was talking about. So we already have our azure sub net that we want to connect to set up. We're gonna deploy the gateway, and we're also going to create the gateway seven it as well.
But you can see that we have 256 addresses in this gateway sub net. And quite frankly, nothing else is going to live in this sub net other than the gateway. So you more than likely would want to select Ah, hire cider range here toe limit your number of dresses and
azure won't let me use 30. So the smallest sub net range I can select is going to be a 29 which gives me eight addresses. And that's because Azure has some reserved things that they insert into all of these sub net ranges to make everything in azure work accordingly.
So we'll leave that at a slash 29 with only eight addresses, because there's no way I need 256 addresses floating around in this address space for the gateway seven. It
I'm gonna go ahead and create a new
and then you have some options here about active, active, and again, this just helps improve or increase our redundancy here for this VP and Gateway and then B g p is going to be dynamic routing option that will advertise some PGP routes for this VP. And but we're gonna leave this that disabled. I don't need to create any tags,
and I'm just gonna hit review, create
Well, that's deploying. I'm gonna go ahead and deploy the other side of this VPN connection doing the exact same thing,
and then we'll be right back. Our virtual network gateways have finally finished deploying, and I want to warn you at this point that for you, when you're stepping through this thes virtual network gateways can take an exceptionally long time to deploy. That is, Ah, I wouldn't say it's a known issue, but it is a common
complaint of azure administrators that this process takes us along with. It does.
And Microsoft has acknowledged that they are working on speeding up this particular deployment. I know for me in this particular example, one of the gateways deployed in 30 minutes and the other one took well over an hour. But now that those air finishing deploying, we're gonna go ahead and go in here and we're gonna search. All service is and we're