Its Day 48 of my 100 Days of Cloud Journey, and today I’m going to run through a quick demo of how to set up Azure Network Adapter.
In previous posts, I looked at the various connectivity offerings that Azure offer to allow access into a Virtual Network from either a peered VNET, an on-premise location using Site to Site VPN or Express Route, or a direct connection from a client PC using a Point to Site VPN.
For the majority of companies who are hosting resources in Azure, a Site to Site VPN will be the most commonly used model, however in most cases this extends their entire on-premise or datacenter location into Azure, and also give them visibility at the very least of all hosted resources.
Azure Network Adapter is a way to set up connectivity from on-premise servers running Windows Server 2019 directly into the Azure Virtual Network of your choice. By using Windows Admin Center to create the connection, this also creates the VPN Gateway Subnet and Certificate options. This eases the pain of creating connections between on-premises environments and Microsoft Azure public cloud infrastructure.
Lets have a look at how this is configured. There are some pre-requisites we need to make this work:
Using Azure Network Adapter to connect to a virtual network requires the following:
An Azure account with at least one active subscription.
An existing virtual network.
Internet access for the target servers that you want to connect to the Azure virtual network.
A Windows Admin Center connection to Azure.
The latest version of Windows Admin Center.
From Windows Admin Center, we browse to the Server we want to add the Azure Network Adapter to. We can see under Networks we have the option to “Add Azure Network Adapter (Preview)”:
When we click, we are prompted to register Windows Admin Center with Azure:
Clicking this brings us into the Account screen where we can register with Azure:
Follow the prompts and enter the correct information to connect to your Azure Tenant
Once we’re connected to Azure, we go back to our Server in Windows Admin Center and add our Azure Network Adapter:
What this will do is both create the network connection to Azure (which is effectively a Point-to-Site VPN Connection) from our Server, but it also creates the VPN Gateway Subnet on the Virtual Network in our Azure Subscription. We also see that we can select a VPN Gateway SKU. When we click the “How much does this cost?” link, we can see pricing details for each of the available SKU’s.
We click create and see Success!! We also see that this can take up to 35 minutes to create.
We then get a notification to say our Point to Site Client Configuration has started:
And once that’s completed, we can see our VPN is up and connected:
And we can also see our gateway resources have been created in Azure:
Now, lets see if we can connect directly to our Azure VM. We can see the Private IP Address is 10.30.30.4:
And if we try to open an RDP connection from our Server to the Azure VM, we get a response asking for credentials:
You can disconnect or delete the VPN connection at any time in Windows Admin Center by clicking on the “ellipses” and selecting the required option:
Go ahead and try the demo yourelves, but as always don’t forget to clean up your resources in Azure once you have finished!
It’s Day 13 (unlucky for some….) of 100 Days of Cloud, and today it’s a brief post on Azure Site-to-Site VPN Connectivity back to your on-premise network.
In the last post, I looked at Point-to-Site VPN, how to set that up in simple steps to connect your endpoints to an Azure Virtual Network using a VPN Client.
There is little difference in the 2 setups, and for that reason (along with the fact that I don’t have any supported hardware or sites to test this from) I’m not going to run through the demo in this post.
A brief history of Site to Site VPN
As its name states, a Site-to-Site VPN is a means of connecting multiple sites together so that can exist as part of the same Network. In companies with Sites across multiple geographic locations, Site-to-Site VPN’s connected these sites together to enable users to access resources across those multi-site environments, there site became part of the organization’s WAN (Wide Area Network). The WAN could exist in 2 different architectures:
Hub and Spoke, where all “remote” sites connected back to a single head office hub
Mesh, where all sites connected to each other
Azure Site to Site VPN
A Site-to-Site VPN tunnel is great for when you need a persistent connection from many on-premise devices or an entire site to your Azure network. This is an ideal option for creating hybrid cloud solutions where you need to be able to connect to your Azure resources seamlessly.
On the Azure side, you’ll need to create your virtual network just like you did with P2S, but this time you are also going to need to define your on-prem network. This is where using this solution is going to take a little more thought and planning. Just like any Site-to-Site VPN, both sides need to know what IP address range should be sent over the tunnel. This means that in Azure you are going to need to configure each on-prem network that you want Azure to be connected to and the subnets that it should be able to communicate with.
Let’s do a quick comparison of exactly what’s required for a S2S VPN:
– A Virtual Network
– A VPN Gateway
– A Local Network Gateway (this is the subnet on your local)
– Local Hardware that has a valid static Public IPv4 Address
Local Network Gateway
The local network gateway is a specific object that represents your on-premises location (the site) for routing purposes. You give the site a name by which Azure can refer to it, then specify the IP address of the on-premises VPN device to which you will create a connection.
You also specify the IP address prefixes that will be routed through the VPN gateway to the VPN device. The address prefixes you specify are the prefixes located on your on-premises network. If your on-premises network changes or you need to change the public IP address for the VPN device, you can easily update the values later.
Supported Local Hardware
Microsoft has defined a list of supported devices that support VPN Connections, which can be found here. It also provides setup scripts for major vendors such as Cisco, Juniper and Ubiquity. Not all devices are listed, and even of not listed may still work.
Authentication
Another difference between S2S and P2S is that S2S is authenticated using a pre-shared key (PSK) instead of certificates because it uses Internet Protocol Security (IPsec) rather than Secure Socket Tunneling Protocol (SSTP). You can have the Azure tools generate a PSK for you, or you can manually configure one that you have generated yourself. This means that the networking equipment will handle maintaining the encryption of the tunnel itself, and the computers and devices communicating over the tunnel don’t each need an individual certificate to identify themselves and encrypt their own connections.
It’s Day 12 of 100 Days of Cloud, and as promised in the last post, I’m going to set up a Point-to-Site (P2S) VPN Gateway Connection.
In a later post I’ll deal with Site-to-Site (S2S) VPN’s. These are the most common type of VPN where you create a connection between your local site network and a remote network (such as Azure, AWS or another remote site in your organization).
Point-to-Site (P2S) Overview
As always, let’s get some concepts and scenarios first. A Point-to-Site VPN gateway connection let you create a secure connection to your Azure Virtual network from your individual client computer. This is useful in the following scenarios:
Working from a remote location or from home where you need to access company resources.
If you only have a small number of clients that need to connect to a specific resource and don’t want to set up a Site-to-Site (S2S) connection.
Traditional Examples of P2S VPN connections would be:
SSL VPN Client (from vendors such as Cisco/Fortinet), where users would authenticate using RADIUS authentication with optional MFA.
Direct Access, where a VPN Connection would automatically connect once internet connectivity is established on the client device.
P2S VPN’s use the following network protocols:
OpenVPN — This is SSL/TLS based, and can be used with Windows, Android, iOS (v 11.0 and above), Linux and Mac (macOS 11.0 and above).
Secure Socket Tunneling Protocol (SSTP) — this is a proprietary TLS-based VPN protocol, and is only supported on Windows Devices.
IKEv2 VPN — a standards based IPSec VPN that can only be used to connect from Mac devices (macOS 11.0 and above)
So as we can see from the above, when planning a P2S deployment, you’ll need to know exactly what the Client Machines are that need to connect so you can use the correct protocols.
There are 3 ways that P2S VPN connections can authenticate:
Azure Certificate Authentication — this uses a certificate that is present on the client device. You need 2 certificates — firstly, you can generate a self-signed certificate or use a root cert generated using an Enterprise solution which must be uploaded to Azure. Second, client certificates are generated from a Trusted Root CA and installed on the client devices. The certificate validation is done on the VPN Gateway.
Azure AD Authentication — this allows users to use their Azure AD credentials to connect. This is only supported with OpenVPN protocol and Windows 10, and requires the use of the Azure VPN Client. This solution allows you to leverage Multi-Factor Authentication (MFA).
On-Premise AD DS Authentication — this solution allows users to connect to Azure using their organization domain credentials. It requires a RADIUS server that integrates with the AD server. The RADIUS server can be in Azure or On-Premise, however in the On-Premise scenario, this requires a S2S VPN Connection between Azure and the On-Premise network. The diagram below shows the requirements for this scenario:
Finally, client requirements. Users use the native VPN clients on Windows and Mac devices for P2S. Azure provides a VPN client configuration zip file that contains settings required by these native clients to connect to Azure.
For Windows devices, the VPN client configuration consists of an installer package that users install on their devices.
For Mac devices, it consists of the mobileconfig file that users install on their devices.
The zip file also provides the values of some of the important settings on the Azure side that you can use to create your own profile for these devices. Some of the values include the VPN gateway address, configured tunnel types, routes, and the root certificate for gateway validation.
That’s the theory side out of the way, let’s do a quick Demo and get this set up. I’m going to use the Certificate Authentication method for the demo.
Point-to-Site (P2S) Overview
The pre-requisite requirements for setting up a P2S connection are quite simple. I need something to connect to. So I’ll use the following:
– Resource Group (I’ll use the Prod_VMs RG I set up previously)
– Virtual Network
– Virtual Machine, or some other resource that I can connect to over the VPN once the connection is established.
Now I need to create some resources for the P2S VPN to work. I’ll create the Virtual Network Gateway first:
Virtual Network Gateway
Give the gateway a name and define the VPN type. I’ll select gateway type VPN and VPN type Route-based. Choose SKU type. Select the virtual network (in our case ProdVM1) and create a new public IP address. Click Create.
VPN Gateway throughput and connection limit capabilities are defined by the VPN SKU type. I’m using “Basic” SKU for the demo purposes only. More information on VPN SKUs can be found here, and it’s important to refer to this when planning the deployment in a Production environment.
It may take up to 45 minutes to provision the virtual network gateway.
Generate a Root Certificate
The root certificate I generate is what I’ll to upload to Azure, as this will be used to authenticate the P2S Connection. After I create the root certificate, I’ll export the public certificate data (not the private key) as a Base64 encoded X.509 .cer file. Then, I’ll upload the public certificate data to the Azure.
I’ll open PowerShell ISE as an Administrator and run the following script:
Now that I have certs in place, I need to export root certificate to upload it in Azure.
Export the root certificate public key (.cer)
Hit the Windows Key + “R”, to bring up the run dialog box and type in “certmgr.msc”. When the management console opens, I can see my newly created certificates in “Current User\Personal\Certificates”. I’ll right-click on the root certificate, go to All Tasks > Export:
In the Wizard, click Next:
Select No, do not export the private key, and then click Next:
On the Export File Format page, select Base-64 encoded X.509 (.CER), and then click Next:
For File to Export, I’ll browse to the location to where I want to export the certificate. Give the file a name, and click Next:
Click Finish to export the certificate:
The certificate is successfully exported, and looks similar to this:
Now I’ll open the exported file in Notepad. The section in blue contains the information that is uploaded to Azure.
Configure Point-to-Site Connection
The next step is to configure the point-to-site connection. This where we define the client IP address pool the VPN Clients will use when connected, as well as importing the certificate.
Back in the Portal, I’ll go to my Virtual Network Gateway that I created above and select the option for “Point-to-site configuration” in the menu:
Click on Configure now:
In new window type IP address range for VPN address pool. In this demo, I will be using 20.20.20.0/24.
In the same window, there is a place to define a root certificate. Under root certificate name type the cert name and under public certificate data, paste the root certificate data (you can open the cert in notepad to get data).
Then click on Save to complete the process.
Note: when you paste certificate data, do not copy — –BEGIN CERTIFICATE — — & — –END CERTIFICATE — — text.
Testing VPN connection
Once that’s completed, it’s time to test and see if it works!
From the “Point-to-site configuration” page, I’ll click on “Download VPN Client”:
This downloads a ZIP file where I have both x86 and x64 Clients. When I double click on the VPN client setup, it asks if I wish to install a VPN client for my Virtual Network:
Once this finishes, I can see a new connection under windows 10 VPN page:
Click on connect to VPN. Then it will open up this new window. Click on Connect:
Then run ipconfig to verify IP allocation from VPN address pool:
Now, I can check if I can ping my “ProdVM1” Virtual machine across the VPN:
And can I RDP to it?:
Yes I can …..
And that’s how to set up a Point-to-Site (P2S) VPN Connection.
Michael Durkan 