Azure VPN Gateway
(Edit: I’ve also now posted about how to do this with a Palo Alto Firewall as well, you can see that post here: https://thetechl33t.com/2020/11/18/azure-site-to-site-vpn-with-palo-alto-firewall/ )
If you’re like me, you like to have a little bit more control over your network (home or business) than is available with the ISP-provided router – enter PFSense. The Netgate Appliances work very well and I’ve worked with plenty of home networks, as well as small and medium businesses that have used them as their cost-effective Router/Firewall/VPN appliance combination.
Now, how do we setup a Site-to-Site VPN with our infrastructure hosted in Azure with PFSense. It’s actually pretty easy! Let’s jump into it.
The first thing we need to do in Azure is setup a virtual network (or vnet). A virtual network is a regional construct, meaning that it cannot span multiple regions. I’m going to choose the “West US” region for now since that’s where i’ll be building my resources after this is configured.
In this particular setup I’m using 10.2.0.0/16 as my virtual network address space and have designated two subnets for a later project.
After the virtual network is configured, we’ll need to create a “Gateway Subnet” which is a specific prerequisite to deploying a VPN Gateway into the virtual network.
Alright, the network and subnets are all setup in Azure. Now let’s go create a Virtual Network Gateway to act as our PaaS VPN appliance. I’m going to be using a route-based VPN, so I’ll use that VPN type and choose the virtual network that we just created. You’ll notice that it also selects the special GatewaySubnet that was created for the VPN Gateway. I’m going to create a new public IP address to be associated with the VPN Gateway, and won’t be using active-active or BGP for this lab so I’ll leave those disabled.
The VPN Gateway takes about 20-30 minutes to deploy so go ahead and go stretch and grab a cup of coffee. Once it’s done we’ll go in and create a “connection”, which we’ll designate as “site-to-site IPSec”, then set the PSK that will be used here and on the on-premises appliance.
You’ll need to also create a local network gateway which is an Azure resource that represents the information about the on-premises VPN appliance and IP ranges. You’ll want to enter the public IP of the PFSense appliance on-premises and whatever address space you’d like to add to the route table of the virtual network so it knows to route those addresses across the VPN through the gateway.
Once that’s done we’ll go grab the public IP of the VPN Gateway from the overview page so we can go setup the PFSense side of the VPN.
Alright, now let’s go setup an IPSec VPN in PFSense. Open the IPSec VPN settings page and let’s create a Phase 1 configuration.
I will want to select the Authentication Method of Mutual PSK and enter the PSK we setup on the Connection on the VPN Gateway in the “Pre-Shared Key” field. I’m going to be connecting to some other resources with this setting so I am using both AES 128 and 256 with relative SHA 256 hashes and both DH groups 2 and 14. I recommend reviewing the documentation on cryptographic requirements and Azure VPN gateways though for reference.
Next let’s create a Phase 2 configuration for the IPSec VPN. I’m designating 10.0.0.0/8 to the VPN assuming that I may expand my Azure environment at some later point. If we wanted to be exact this would be the 10.2.0.0/16 address space that we configured in our virtual network. For the Encryption Algorithms required, please see the cryptographic requirements documentation noted above. If you wanted to automatically ping a host in Azure to bring up/keep up the tunnel you can configure that here as well.
Now that we’ve created both the Phase 1 and Phase 2 configurations we can “apply changes” to add those changes to the running configuration.
After the settings have saved the tunnel will take a minute to come up, you may take this time to spin up a quick VM in your Azure virtual network to use for testing connectivity. Once that tunnel comes up you can see the connection statistics on the IPSec Status page. Similarly if you look at the overview page of the site-to-site connection we created on the VPN Gateway on Azure you can see the tunnel status and connection statistics.
For troubleshooting purposes, there is a “VPN Troubleshoot” functionality that’s a part of Azure Network Watcher that’s built into the view of the VPN Gateway. You can select the gateway on which you’d like to run diagnostics, select a storage account where it will store the sampled data, and let it run. If there are any issues with the connection this will list them out for you. It will also list some specifics of the connection itself so if you want to dig into those you can go look at the files written to the blob storage account after the troubleshooting action is complete to get information like packets, bytes, current bandwidth, peak bandwidth, last connected time, and CPU utilization of the gateway. For further troubleshooting tips you can also visit the documentation on troubleshooting site-to-site VPNs with Azure VPN Gateways.
That’s it, all done! The site-to-site VPN is all setup. The VPN gateway in Azure really makes this process very easy, and the PFSense side is fairly easy to setup as well.
If you have any questions or suggestions for future blog posts feel free to comment below, or reach out to me via email, twitter, or LinkedIn. I hope I’ve made your day at least a little bit easier!
For the money, it’s hard to beat the Azure VPN Gateway. Until recently though, Point-to-Site VPNs were a bit clunky because they needed mutual certificate authentication. It wasn’t bad, but it certainly wasn’t good. Thankfully, Microsoft now allows RADIUS backed authentication. This post is how you impliment said configuration.
To start off, here is my environment information I’m using to setup this configuration.
Virtual Network: “raidus-vnet”
Virtual Network Address Space: 10.1.0.0/24
Virtual Network VM Subnet: 10.1.0.0/28
Virtual Network Gateway Subnet: 10.1.0.16/28
VPN Gateway SKU: VpnGW1
VPN Client Address Pool: 172.28.10.0/24
Domain Controler/NPS Server Static IP: 10.1.0.10
Virtual Network (VNET) Setup:
You most likely already have a VNET where you will be configuring this setup, but if you don’t you need to create one with two subnets. One subnet for infrastructure, and one “Gateway Subnet”. The Gateway Subnet will be used automatically, and is required, when you configure the VPN Gateway.
VPN Gateway Setup:
The Azure VPN Gateway is just about as easy as it gets to configure and to managed (sometimes to a fault). The only caveat you need to be aware of in this scenerio, is that RADIUS Point-to-Site authentication is only available on the SKU “VPNGW1” and above. You’ll then need to choose the vnet where you have created the VPN Gateway, and create a Public IP Address resource.
This will take anywhere from 20-45 minutes to provision, as noted. While that’s running, you can provision your NPS (Network Policy Server) VM. This being a test environment, I provisioned a VM to be both the domain controler and the NPS box. Make sure to set a static IP on the NPS box’s NIC in Azure, you’ll need a static for your VPN configuration. I used 10.1.0.10.
After complete, you will need to configure the VPN Gateway’s Point-to-Site configuration. Choose “RADIUS authentication”, enter in the static IP of the will-be NPS server, and set a Server Secret. This being a test environment, my password is obviously not as secure as I hope yours would be.
Now, go back into that VM that was created earlier and install the NPS role.
After it’s installed, you need to create a Network Policy with a condiational access clause (I used a group in AD) and tell it what security type you want to allow.
Next, you’ll need to create a Client Access Policy. Here you need the IP of the VPN Gateway you created, and the shared secret. Here is the interesting bit, you can’t view the IP of your VPN Gateway in the Gateway Subnet. If you looked at “Connected Devices” in the VNET the VPN Gateway doesn’t show any IP. I know that the VPN Gateway is deployed (behind the scenes) as an H/A pair, but I would assume they’re using a floating IP that they could surface. Anyways, there is no real way to find it – but it looks like (after testing with a dozen different deployments) it uses the 4th available IP in the subnet. This subnet being a 10.1.0.16/28, the 4th IP is 10.1.0.21. This is the IP that goes in the address of the RADIUS Client.
Next, I configure NPS Accounting. You don’t have to do this, but I think it helps for the sake of connection logging and for troubleshooting. You can log a few different ways, and choose here just to use a text file to a subfolder I created called “AzureVPN”.
Generate VPN Client Package:
Now that everything is set, you need to generate a VPN Client Package to distribute to your users.
After it is installed, you can see the VPN Connection in the VPN list and users can logon using their domain credentials.
After logging in, we can go back and look at the accounting log which shows us the successfull authentication of that user.
There we go, connecting to an Azure VPN Gateway with RADIUS authentication using domain credentials. I think we can all thank Microsoft for this one, and not having to do cert management anymore.
I hope I’ve made your day at least a little bit easier.