WEBVTT 0:00:01.760000 --> 0:00:08.800000 In this video, we're going to take a look at virtual network connectivity. 0:00:08.800000 --> 0:00:14.440000 And specifically, we're going to take a look at express route and some 0:00:14.440000 --> 0:00:16.860000 of the details related to express route. 0:00:16.860000 --> 0:00:21.820000 We're going to look at the VPN gateway and what some of the options are 0:00:21.820000 --> 0:00:25.180000 and the configuration is for the VPN gateway. 0:00:25.180000 --> 0:00:31.100000 And we're going to take a look at virtual network peering. 0:00:31.100000 --> 0:00:36.420000 Let's start by digging in a bit into express route. 0:00:36.420000 --> 0:00:44.120000 Express route is designed to provide connectivity between your on-premises 0:00:44.120000 --> 0:00:47.540000 environment and the Azure environment. 0:00:47.540000 --> 0:00:52.080000 Now, I've got an Azure virtual network on this diagram and that certainly 0:00:52.080000 --> 0:00:58.200000 plays a part, but the connectivity is really into Azure itself as I'll 0:00:58.200000 --> 0:01:00.680000 explain momentarily. 0:01:00.680000 --> 0:01:06.240000 Now, in order to facilitate express route, you need an express route provider. 0:01:06.240000 --> 0:01:10.940000 Every region that supports express route has express route providers. 0:01:10.940000 --> 0:01:14.740000 Most regions have multiple express route providers. 0:01:14.740000 --> 0:01:20.800000 The first step in establishing express route is to contract with one of 0:01:20.800000 --> 0:01:27.280000 those providers and to create a connection between your environment and 0:01:27.280000 --> 0:01:31.860000 the provider. In the big picture, there's three different types of connections 0:01:31.860000 --> 0:01:37.360000 that can be created between your environment and the provider. 0:01:37.360000 --> 0:01:42.320000 They are co-located and that means exactly what it sounds like, that your 0:01:42.320000 --> 0:01:46.200000 assets that you want to connect into Azure are actually physically co 0:01:46.200000 --> 0:01:50.780000 -located at the express route providers exchange site. 0:01:50.780000 --> 0:01:57.420000 Point to point, which is typically a wired connection, something such 0:01:57.420000 --> 0:02:06.940000 as fiber optic between your environment and the express route provider. 0:02:06.940000 --> 0:02:11.780000 That is, by the way, the co-located is going to be a layer two. 0:02:11.780000 --> 0:02:16.320000 The point to point is either going to be a layer two or a managed layer 0:02:16.320000 --> 0:02:21.760000 three connectivity or you can have an any to any if you have an existing 0:02:21.760000 --> 0:02:29.880000 WAN topology, then you can tie in the express route provider really just 0:02:29.880000 --> 0:02:35.040000 as another remote site, think of it as a branch office, tied into your 0:02:35.040000 --> 0:02:41.720000 MPLS network. All of this connectivity between your on-premises site or 0:02:41.720000 --> 0:02:46.080000 even if you're not on-premises, your co -location, that is configured between 0:02:46.080000 --> 0:02:47.440000 you and the express route provider. 0:02:47.440000 --> 0:02:52.940000 That is really a separate configuration from what you would do in Azure. 0:02:52.940000 --> 0:02:58.480000 Now as far as Azure is concerned, you create circuits between the express 0:02:58.480000 --> 0:03:03.280000 route provider and the Azure environment, your subscription. 0:03:03.280000 --> 0:03:09.900000 Circuits are by definition redundant so that you have two active active 0:03:09.900000 --> 0:03:16.200000 pathways between the express route provider and the Azure environment. 0:03:16.200000 --> 0:03:18.660000 Those pathways are on a private backbone. 0:03:18.660000 --> 0:03:23.540000 They're not going over the public internet at all. 0:03:23.540000 --> 0:03:30.340000 Now in order to take advantage of these circuits, you will set up express 0:03:30.340000 --> 0:03:34.860000 route gateways in your virtual networks. 0:03:34.860000 --> 0:03:39.980000 Express route gateway is going to connect your virtual network into the 0:03:39.980000 --> 0:03:46.040000 circuit that effectively logically represents your on-premises network. 0:03:46.040000 --> 0:03:50.720000 In the big picture, that is how you configure express route. 0:03:50.720000 --> 0:03:54.680000 Now obviously there are details that you would go into it. 0:03:54.680000 --> 0:03:58.320000 A lot of those details are going to be dependent upon the express route 0:03:58.320000 --> 0:04:04.160000 provider and there are consulting companies out there. 0:04:04.160000 --> 0:04:08.920000 There's many that are certified by Microsoft to help you implement the 0:04:08.920000 --> 0:04:10.580000 express route architecture. 0:04:10.580000 --> 0:04:16.000000 Now over express route, one thing that is important is you have two types 0:04:16.000000 --> 0:04:17.100000 of what are called peering. 0:04:17.100000 --> 0:04:21.360000 There used to be three types but two of those have been really merged 0:04:21.360000 --> 0:04:27.440000 into one. The two types of peering are Microsoft peering and private peering. 0:04:27.440000 --> 0:04:33.960000 Private peering is going to allow you to route communication between your 0:04:33.960000 --> 0:04:38.880000 on-premises environment through express route to virtual networks, to 0:04:38.880000 --> 0:04:41.860000 the private IP side of virtual networks. 0:04:41.860000 --> 0:04:44.940000 That is what private peering does. 0:04:44.940000 --> 0:04:50.680000 Microsoft peering will route connections between your on-premises environment 0:04:50.680000 --> 0:04:58.580000 and public endpoints in Azure in Microsoft 365 and Dynamics 365. 0:04:58.580000 --> 0:05:03.780000 It will route all of that communication over express route rather than 0:05:03.780000 --> 0:05:09.520000 over the public internet, giving you private communication from your on 0:05:09.520000 --> 0:05:15.800000 -premises environment not only to other virtual networks but also to services 0:05:15.800000 --> 0:05:21.880000 such as Azure SQL databases, Azure storage, Cosmos DB. 0:05:21.880000 --> 0:05:25.500000 All of these can be connected from your on-premises going over the private 0:05:25.500000 --> 0:05:28.800000 connection through the Azure environment. 0:05:28.800000 --> 0:05:33.860000 Now one thing you do want to be careful with if you are using services 0:05:33.860000 --> 0:05:42.140000 such as Azure storage, Azure SQL database, Cosmos DB and you set up service 0:05:42.140000 --> 0:05:48.440000 endpoints. You cannot currently set a service endpoint that would allow 0:05:48.440000 --> 0:05:57.760000 connectivity directly to a gateway site to site either. 0:05:57.760000 --> 0:06:02.600000 In that case if you set up your service endpoint which is a very good 0:06:02.600000 --> 0:06:09.140000 thing to set up, you will have to add some IP address exceptions. 0:06:09.140000 --> 0:06:13.700000 Those will have to refer to the, in the case of express route, the NATED 0:06:13.700000 --> 0:06:18.060000 IP addresses and you can work with your express route provider to find 0:06:18.060000 --> 0:06:23.260000 out what NATED IP addresses you would need in order to be able to access. 0:06:23.260000 --> 0:06:27.800000 Again, the idea being that you have got a storage account, you have a 0:06:27.800000 --> 0:06:31.960000 service endpoint set up or multiple service endpoints and then in addition 0:06:31.960000 --> 0:06:35.000000 to the service endpoints, you would have to work with your express route 0:06:35.000000 --> 0:06:40.640000 provider to find the IP addresses that would be used to connect into that 0:06:40.640000 --> 0:06:44.680000 service. So that is express route, big picture of course. 0:06:44.680000 --> 0:06:49.100000 Now let's move over to a VPN gateway. 0:06:49.100000 --> 0:06:54.220000 With a VPN gateway, you have the same connectivity architecture. 0:06:54.220000 --> 0:07:00.660000 I'm connecting an on-premises environment into the Azure environment. 0:07:00.660000 --> 0:07:06.760000 Okay, in order to do this, I'm going to configure on the Azure side within 0:07:06.760000 --> 0:07:11.740000 a virtual network, I am going to configure a VPN gateway. 0:07:11.740000 --> 0:07:15.860000 The VPN gateway must have its own subnet. 0:07:15.860000 --> 0:07:20.620000 By the way, the express route gateway also have to have its own subnet 0:07:20.620000 --> 0:07:23.600000 and the subnet is gateway subnet. 0:07:23.600000 --> 0:07:29.600000 You have to have a dedicated subnet gateway subnet and that will be used 0:07:29.600000 --> 0:07:32.260000 by your VPN gateway. 0:07:32.260000 --> 0:07:35.820000 If you have both a VPN and an express route gateway, they will both use 0:07:35.820000 --> 0:07:38.160000 the same gateway subnet. 0:07:38.160000 --> 0:07:40.160000 Nothing else can be in the gateway subnet. 0:07:40.160000 --> 0:07:44.240000 Now, once I have the VPN gateway, I'm also going to have on the on-prem 0:07:44.240000 --> 0:07:47.220000 side some VPN appliance. 0:07:47.220000 --> 0:07:51.300000 Pretty much, and this is a very broad statement, maybe I won't put it 0:07:51.300000 --> 0:07:59.340000 quite like that, there are many VPN devices, appliances that will be that 0:07:59.340000 --> 0:08:04.080000 are certified and will work properly with Azure VPN. 0:08:04.080000 --> 0:08:08.240000 Each device is going to have its own configuration process and you can 0:08:08.240000 --> 0:08:12.620000 actually find published sets of configurations from Microsoft as well 0:08:12.620000 --> 0:08:16.340000 as from the vendors of the various VPN appliances. 0:08:16.340000 --> 0:08:21.620000 I have to have both of those and they're going to end up needing to communicate. 0:08:21.620000 --> 0:08:27.040000 The way I would set this up first, within Azure, I'm going to represent 0:08:27.040000 --> 0:08:32.620000 the VPN appliance with a local VPN gateway. 0:08:32.620000 --> 0:08:41.520000 The local gateway really is just the settings for the VPN appliance that's 0:08:41.520000 --> 0:08:43.280000 on your on-premises environment. 0:08:43.280000 --> 0:08:48.840000 For example, the public IP address of the endpoint for that gateway as 0:08:48.840000 --> 0:08:54.460000 well as the local IP address ranges of whatever IP addresses you have 0:08:54.460000 --> 0:08:55.460000 on the other side. 0:08:55.460000 --> 0:09:00.780000 Those IP address ranges are going to be used as part of the built-in routing 0:09:00.780000 --> 0:09:04.720000 capability, the system routing capability, so that when requests go to 0:09:04.720000 --> 0:09:08.960000 those IP addresses, they will automatically go over the gateway. 0:09:08.960000 --> 0:09:13.440000 So that's the configuration that I need within my Azure environment. 0:09:13.440000 --> 0:09:16.540000 And again, on the other side, the VPN appliance, you will need to configure 0:09:16.540000 --> 0:09:20.980000 that. You will need to point it to the public endpoint of your VPN gateway. 0:09:20.980000 --> 0:09:26.820000 And depending on what the appliance is, there will be additional configuration. 0:09:26.820000 --> 0:09:30.520000 Once you set that up, then you're going to set up your connections. 0:09:30.520000 --> 0:09:35.180000 And you set up your connections in two directions. 0:09:35.180000 --> 0:09:40.580000 And these connections use a pre -shared key, PSK architecture. 0:09:40.580000 --> 0:09:48.480000 And they are based on an IKE IP set policy that defines things like the 0:09:48.480000 --> 0:09:49.520000 encryption algorithm. 0:09:49.520000 --> 0:09:51.340000 There's a built-in policy. 0:09:51.340000 --> 0:09:56.440000 You can also create your own custom policies under some circumstances. 0:09:56.440000 --> 0:10:00.700000 And then you would also configure the connection from your on-prem back 0:10:00.700000 --> 0:10:03.780000 into your Azure environment. 0:10:03.780000 --> 0:10:11.060000 Now, there are a few additional things you want to know. 0:10:11.060000 --> 0:10:14.880000 Put this here in full screen for a moment, so it's the largest possible. 0:10:14.880000 --> 0:10:16.360000 It's quite a bit of it. 0:10:16.360000 --> 0:10:19.500000 Two different ways of setting up a VPN gateway. 0:10:19.500000 --> 0:10:22.320000 There's route-based or policy-based. 0:10:22.320000 --> 0:10:27.840000 In general, given the choice, you are going to choose a route-based VPN 0:10:27.840000 --> 0:10:32.680000 gateway. Because it has far more features. 0:10:32.680000 --> 0:10:35.380000 For example, it is dynamic. 0:10:35.380000 --> 0:10:38.760000 So you're not going to have to do so much pre-configuration. 0:10:38.760000 --> 0:10:45.680000 You've got BGP. It supports active, active multi-connections. 0:10:45.680000 --> 0:10:49.460000 So if I have multiple VPN devices on -premises, I can connect those and 0:10:49.460000 --> 0:10:53.480000 have those work in an active, active load sharing, as well as availability 0:10:53.480000 --> 0:10:58.940000 architecture. This is full feature. 0:10:58.940000 --> 0:11:04.060000 It has things like custom IKE and IPsec policy. 0:11:04.060000 --> 0:11:10.980000 It has a range of performance tiers. 0:11:10.980000 --> 0:11:17.760000 It has connectivity for the ability to establish multiple connections 0:11:17.760000 --> 0:11:21.080000 to different environments. 0:11:21.080000 --> 0:11:25.620000 And again, it's typically the one that you are going to want to use. 0:11:25.620000 --> 0:11:29.880000 Policy-based is based on static policy. 0:11:29.880000 --> 0:11:33.980000 It is only available with basic tier. 0:11:33.980000 --> 0:11:39.880000 There's basic, there's standard, there's three VPN tiers, VPN 1, 2, and 0:11:39.880000 --> 0:11:43.080000 3. And then there's also high performance. 0:11:43.080000 --> 0:11:49.660000 As you go up in tier, you get more performance and also more options. 0:11:49.660000 --> 0:11:54.480000 This can only have one route set up and it has limited point-to-site capabilities. 0:11:54.480000 --> 0:12:05.280000 For example, you can only use IKE V1 with a policy-based VPN gateway. 0:12:05.280000 --> 0:12:07.100000 So that's the VPN gateway. 0:12:07.100000 --> 0:12:11.880000 Again, what are the key takeaways with the VPN gateway? 0:12:11.880000 --> 0:12:20.120000 Key takeaways are that you want route -based and you have to configure 0:12:20.120000 --> 0:12:24.360000 the connection on the Azure side, you're going to set up a local gateway 0:12:24.360000 --> 0:12:28.720000 that represents your on-prem environment. 0:12:28.720000 --> 0:12:33.100000 Now, let's talk about virtual network pairing. 0:12:33.100000 --> 0:12:39.260000 It's the way we're going to connect my multiple virtual networks within 0:12:39.260000 --> 0:12:44.040000 Azure together. I can use VPN gateways. 0:12:44.040000 --> 0:12:46.680000 That would be called a VNet -to-VNet connection. 0:12:46.680000 --> 0:12:51.240000 And a VNet-to-VNet connection is really the same as a site-to-site connection, 0:12:51.240000 --> 0:12:57.420000 except rather than configuring a VPN gateway on Azure with a VPN appliance 0:12:57.420000 --> 0:13:03.280000 on the on-prem side, you're simply configuring two VPN gateways. 0:13:03.280000 --> 0:13:09.220000 With pairing, you are setting up a direct connection between virtual networks. 0:13:09.220000 --> 0:13:14.020000 If those virtual networks are in the same region, then you're going to 0:13:14.020000 --> 0:13:18.100000 have performance that is equivalent to having the virtual machines in 0:13:18.100000 --> 0:13:19.040000 the same virtual network. 0:13:19.040000 --> 0:13:23.520000 Now, if I've got the virtual machines in the same virtual network or in 0:13:23.520000 --> 0:13:27.980000 the same region and I've got connectivity between them, why would I even 0:13:27.980000 --> 0:13:30.100000 need multiple virtual networks? 0:13:30.100000 --> 0:13:34.520000 There may be a host of reasons for having multiple virtual networks. 0:13:34.520000 --> 0:13:37.180000 It may just be part of the architecture of your system. 0:13:37.180000 --> 0:13:42.040000 You may have one virtual network for your custom outward-facing applications, 0:13:42.040000 --> 0:13:45.040000 another virtual network for your backend servers. 0:13:45.040000 --> 0:13:49.400000 You may have different administrative groups that you want managing different 0:13:49.400000 --> 0:13:54.180000 virtual networks and multiple reasons that you can do this. 0:13:54.180000 --> 0:13:58.320000 You can also set up pairing between subscriptions. 0:13:58.320000 --> 0:14:01.400000 So if you have multiple subscriptions and you need to communicate between 0:14:01.400000 --> 0:14:04.660000 those, you can absolutely set up pairing between those. 0:14:04.660000 --> 0:14:07.120000 You can also set up global pairing. 0:14:07.120000 --> 0:14:12.120000 And with global pairing, you've got your virtual networks in different 0:14:12.120000 --> 0:14:14.140000 regions, simple as that. 0:14:14.140000 --> 0:14:18.960000 And when you set up pairing, you're setting up two-period relationships. 0:14:18.960000 --> 0:14:23.620000 You're setting up from, if you will, network A. 0:14:23.620000 --> 0:14:26.580000 You're setting that up to pair with network B and from network B, you're 0:14:26.580000 --> 0:14:28.700000 setting that to pair up with network A. 0:14:28.700000 --> 0:14:32.040000 If they're both in the same subscription, it's very easy to do this, very 0:14:32.040000 --> 0:14:33.640000 easy to do through the portal. 0:14:33.640000 --> 0:14:35.640000 I can click my way through. 0:14:35.640000 --> 0:14:38.400000 If they're not in the same subscription, you're going to need to know 0:14:38.400000 --> 0:14:44.780000 the resource IDs of your networks that you want to connect, because that 0:14:44.780000 --> 0:14:47.600000 is how you set up that pairing connection. 0:14:47.600000 --> 0:14:50.580000 Now, there's another feature of a pairing connection. 0:14:50.580000 --> 0:14:57.420000 If one of the virtual networks in a pairing relationship has a VPN gateway, 0:14:57.420000 --> 0:15:03.940000 you can actually make that VPN gateway available to the other virtual 0:15:03.940000 --> 0:15:08.120000 network. And that's something that is called gateway transit. 0:15:08.120000 --> 0:15:11.580000 I configure my virtual network. 0:15:11.580000 --> 0:15:16.120000 I configure the connection on my virtual network that has the VPN gateway 0:15:16.120000 --> 0:15:20.680000 to allow the gateway transit. 0:15:20.680000 --> 0:15:23.860000 And then, if you will, client virtual network, in this case, a virtual 0:15:23.860000 --> 0:15:29.480000 network on the left, I would set that up to use the remote gateway. 0:15:29.480000 --> 0:15:35.320000 And that way, I've got this ability to set up one centralized virtual 0:15:35.320000 --> 0:15:39.840000 network that can handle traffic from other virtual networks. 0:15:39.840000 --> 0:15:43.080000 And that's typically where you would see, for example, a hub and spoke 0:15:43.080000 --> 0:15:50.600000 topology. OK, those are the basic tools for configuring connectivity. 0:15:50.600000 --> 0:15:56.380000 Let's talk about what some of our virtual network connectivity takeaways 0:15:56.380000 --> 0:15:59.520000 are. First of all, express route. 0:15:59.520000 --> 0:16:03.600000 Make sure that you are comfortable with the physical options, the connectivity 0:16:03.600000 --> 0:16:09.100000 between the on-prem environment and the express route provider, which 0:16:09.100000 --> 0:16:12.260000 would be co-location, site to site, or MPLS. 0:16:12.260000 --> 0:16:16.260000 Also, make sure you understand what the pairing options do. 0:16:16.260000 --> 0:16:22.840000 You have your local pairing and you have your Microsoft pairing. 0:16:22.840000 --> 0:16:30.360000 And with site to site, make sure you understand that that is using a pre 0:16:30.360000 --> 0:16:37.940000 -shared key for encryption and that you have the ability to set your policies, 0:16:37.940000 --> 0:16:45.500000 your security policies, assuming that you're using the appropriate tier. 0:16:45.500000 --> 0:16:48.320000 Point to site. Didn't talk too much about that. 0:16:48.320000 --> 0:16:51.600000 Key thing with point to site is, remember that there's two different authentication 0:16:51.600000 --> 0:16:53.700000 options with point to site. 0:16:53.700000 --> 0:16:57.340000 There is certificate-based authentication, which is considered native 0:16:57.340000 --> 0:16:58.760000 Azure authentication. 0:16:58.760000 --> 0:17:03.560000 Also, if you're using a radius server, you can use that to authenticate 0:17:03.560000 --> 0:17:08.580000 individuals coming in and establishing a point to site connection. 0:17:08.580000 --> 0:17:12.120000 With pairing, you just want to make sure that you are comfortable with 0:17:12.120000 --> 0:17:13.380000 the pairing options. 0:17:13.380000 --> 0:17:17.320000 You have regional pairing as well as global pairing. 0:17:17.320000 --> 0:17:21.740000 One thing currently with global pairing, if you are using global pairing, 0:17:21.740000 --> 0:17:25.060000 that does not support Gateway Transit. 0:17:25.060000 --> 0:17:32.880000 In other words, if I have my subnet A that is in Canada Central and I've 0:17:32.880000 --> 0:17:42.360000 got subnet B that is in North Europe, subnet B could have a VPN Gateway. 0:17:42.360000 --> 0:17:46.980000 But subnet A, though I might set up a pairing connection, would not be 0:17:46.980000 --> 0:17:48.840000 able to use that Gateway. 0:17:48.840000 --> 0:17:51.680000 That is something that may change in the future. 0:17:51.680000 --> 0:17:53.380000 That may have changed by the time you watch this. 0:17:53.380000 --> 0:17:55.580000 Definitely something to take a look at. 0:17:55.580000 --> 0:18:00.180000 But your connectivity concepts are laid out here. 0:18:00.180000 --> 0:18:04.140000 Just keep in mind, express route VPN pairing.