One of the core components of Microsoft Azure is Networking. It’s the glue that allows us to connect all the other services inside and outside of Azure. There are fundamentally three ways to connect to resources in Azure Virtual Networks, but each way has its own caveats that you should address during the architectural phase of your project. The three posts in this blog series will cover the three fundamental types of connections to Azure Point-To-Site, Site-To-Site, and Vnet-To-Vnet. For this blog post we will dig down into Point-To-Site connection details of how to connect to Microsoft Azure Virtual Networks to other services like Azure Web Apps, Cloud Services, and even your own On-Premises Resources.
Getting Started with Point-To-Site
Creating a virtual site is pretty easy, pick a name, set an address space then click "ok" and you are done. Each Virtual Network has configuration options that allow you to customize the connection types and integrations with Azure that your project requires. Below you can see that by default there is no Gateway defined for a VPN and we have two options: Site-to-site or point-to-site.
We can connect VM's to this virtual network in Azure at this point, but that is about all we can do because we do not have a Gateway. The Gateway is an external IP address that allows us to connect VPN sessions. In networking, we call this a Peer IP Address. This is the address your device will reach out to in Azure to connect you to the Virtual Network. You can only create two types of Gateways "Static" or "Dynamic" this determines the type of connections that you are allowed to have to your Virtual Network.
: Routing Type would be referred to in the networking community as Policy-based VPN's. Traffic would be encrypted and routed through an interface based on customer-defined policies. A policy is usually defined as an access list. Azure uses IKEv1 for this type of connection. This type of Gateway does not support multiple connections so connecting more than one location for your business will not work. Also, you cannot connect other Virtual Networks or Point-To-Site Connections with this type of gateway.
Routing Type are referred in the networking community as Route-based VPN's; this dynamically provides network address based routing. These types of Gateways use IKEv2. This kind of gateway must be used for Multi-Site VPN connections (Hub Spoke & Mesh), connecting Virtual Networks to other Virtual Networks in Azure, and also Point-to-Site and Site-to-Site connect to the same Virtual Network.
Point-To-Site is used in two scenarios: Connecting PC's to the Virtual Network or connecting Azure Web Apps. When you create a Point-To-Site VPN connection a Dynamic Gateway will be created by default, and your connection blade will give you links to download the VPN Client for your PC. You will have 32bit or 64bit options, but you must first upload a self-signed root certificate.
Authentication with the gateway is based on self-signed root certificates, and this is all that is supported at this time. The best way to do this is to use "makecert.exe" which is an included tool in Microsoft Visual Studio Express 2013. In Command Prompt Run "makecert -sky exchange -r -n "CN=RootCertificateName" -pe -a sha1 -len 2048 -ss My "RootCertificateName.cer "
Next, in the Azure Portal on the Certificates blade, on your virtual network, upload the root certificate that you created. Now you can download the VPN 32/64bit client and connect to the Virtual Network.
To connect an Azure Web App to a Virtual Network select settings on your Web App then Networking and then click on "Setup."
You will see from the list of available networks that only the Virtual Networks with Dynamic Gateways can be selected. In our case it’s "Tardis."
Once you click “OK”, the configuration blade will update. You will notice as indicated by the green status at the top of the page, that the VNET integration is configured and complete.
In my next Blog, I will review Site-To-Site configurations with Azure Virtual Networks. I hope you find this series useful!