Learn the differences between the various gateway topologies, the requirements and limitations for each and when to use each topology.
- [Instructor] Now that we've talked about VPN gateways, let's go ahead and look at the questions that we need to answer for planning and then the topologies that can be used. As always, in Azure, planning is the key, and for our gateways, let's start by asking a few questions. First, do you need a dedicated non-internet connection? Do you have or will you require a public IP? Do you have remote users that need to connect into your infrastructure? Do you require point-to-site and site-to-site to coexist? And finally, do you need to span regions or subscriptions? Once you have answered these questions, we can start exploring the options.
Our next step is to determine our gateway type. And for the most part, the gateway that you choose will be based on the connection type that you need or want to make. Our Azure Gateways include ExpressRoute, a VPN Gateway that can be used for site-to-site connections or point to site connections. We can use a VNet to VNet gateway, or we can use peering, in which case a gateway is not required. Let's go ahead and explore each of these topologies. First, we'll start off with the ExpressRoute. This is a dedicated private connection from your on-premise environment to the Azure data center.
It is a secure, reliable, and extremely fast connection, and it is offered by regional carriers. But there are some considerations you need to understand if you're going to use ExpressRoute. First of all, it is not available in all regions. As always, double check before implementation. Not all services can use ExpressRoute either. Therefore, if you're going to use the Content Delivery Network or CDN, Visual Studio Team Service load testing, multifactor authentication, or Traffic Manager, you'll need to use a different type of topology for these services.
Next, we have the site-to-site connection or the S2S. This is probably the most popular. This will connect your on-premise environment to the Azure infrastructure with an IPsec/IKE VPN tunnel. You can only have one VPN gateway per virtual network, and that's something to keep in mind in your planning. A VPN device is required, as is a public IP address. Next, we have our multisite site-to-site. Here we can connect two on-premise environments through the single VPN gateway.
Keep in mind that all the connections will share the bandwidth, and you do need a route-based VPN. Next, we have our point-to-site. I always think of point-to-site for remote users. Anybody who's behind NAT. The clients connect using a secure connection using SSTP. Basically, they use a VPN client, and the point-to-site does not require a public-facing IP address. If you've used RAS in Windows Server, this will be very familiar to you. But there are some considerations that you need to be aware of when you implement a point-to-site topology.
First of all, your clients must be on Windows 7 or above. Server 2008 R2 and above is supported. Certificates are required, and these can be self-signed, or you can use an existing CA solution. Next, we have our virtual network to virtual network. As with our site-to-site, an IPsec/IKE VPN tunnel is used, and we use this to connect virtual networks in different regions. In our example here, we have a virtual network one in East US, and a virtual network two in the West US.
In order to connect these two networks, you'll need a site-to-site VPN. You can also connect virtual networks that are in different subscriptions using the site-to-site VPN. And finally, if you still have virtual networks in the classic deployment, you'll use this topology to connect to those. And finally, we have our VNet peering. This allows us to connect our virtual networks that are in the same region. In our example here, you'll see that we have both virtual networks in the East US.
Your virtual networks must not have overlapping IPs, and you can also use this topology to connect your virtual networks in the new ARM or the Azure Resource Manager portal back to the classic portal. Now let's take a look at an example of the various topologies of working together. In our example here, we have our New York office, which is connected to a virtual network in the East US using ExpressRoute. We also have a secondary site-to-site connection, just in case our ExpressRoute goes down, and our remote users can also connect into our East US virtual network over a point=to-site connection.
Then we have a London office, which only has a site-to-site connection and our remote users connect in using a point-to-site VPN connection. And you'll notice that our two virtual networks are connecting using a virtual network to virtual network connection. And there you have it, the various connectivity solutions for Azure.
- Designing virtual machines
- Selecting appropriate VM SKUs
- Designing template deployment
- Deploying ARM templates via PowerShell and CLI
- Designing for availability
- Designing Azure Virtual Networks
- Azure VPN and ExpressRoute architecture and design