In a previous post we configured an IPSec route-based S2S VPN Tunnel between pfSense and an Azure VNet.

IPSec dynamic route-based S2S VPN Tunnel between pfSense and an Azure VNet


Now we do the same but instead route-based we set up a policy-based IPSec S2S VPN Tunnel between pfSense and an Azure VNet. For this post I use a new Azure Directory so I have to create all again from scratch including a Virtual Network.


Table Of Contents
  1. Create a Resource Group
  2. Create the Virtual Network (VNet) with Subnets
  3. Create the Virtual Network Gateway
  4. Create the Local Network Gateway
  5. Configure the IPSec Tunnel on PfSense onPrem
  6. Manage the VPN Gateway with PowerShell
  7. Troubleshooting
  8. Set up IPSec route based S2S VPN for AWS and Google's Cloud VPC
  9. Links



Create a Resource Group

First thing I do is to create a new resource group in which all components we need for the S2S VPN Tunnel will be reside.

As I told you this is a newly created Azure Directory, there are no resource groups available and I first need to create a new one.





Create the Virtual Network (VNet) with Subnets

Inside the resource group we can create a new resource so that the resource group is preselected.




Search for Virtual Network and click on Create.







Under IP Addresses I added a new IPv4 address space 172.16.0.0/16 for the VNet and also a Subnet 172.16.10.0/24 inside.

In this subnet we later place our resources like VMs (Iaas) or managed services (PaaS) and therefore they will be accessible over this IPSec Tunnel.


Under security you can choose at the moment between three option.

  • BastionHost
  • DDoS Protection Standard
  • Firewall

Because we do not need a public endpoint with a public IP Address, we can skip this section and keep all three options at disabled. We only access the resources over our S2S policy-based IPSec VPN Tunnel from our onPrem network. Now we can click on Create.

As you can see there is automatically created a new Resource Group named NetworkWatcherRG, we will see later what’s behind this.

Now we can click on our newly created VNet-braintesting.de



Inside the VNet under Settings we click on Subnets and see the previously created subnet 172.16.10.0/24 we use for new resources. To set up the IPSec Tunnel we need to create a Gateway subnet inside this VNet, so click on add Gateway subnet at the top.



The name of this subnet must be GatewaySubnet and connot be changed. Further you should not place any virtual machines or other services in this subnet.

For this subnet we must use a minimum of a /29 subnet, Microsoft recommends to calculate a reserve and better use a /27 subnet.







Create the Virtual Network Gateway

In order to connect the VNet with our onPrem network we need to create a Virtual Network Gateway. So we go back to our resource group an click on Add to create the Gatway inside this resource group.




Be aware of what type of SKU (Stock keeping Unit | Pricing Tier) you choose below for the virtual network gateway. By default the Basic SKU is a legacy SKU and has feature limitations like no support for routed-based vpn with BGP.

Working with virtual network gateway SKUs
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-skus-legacy

Supported configurations by SKU and VPN type
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-skus-legacy#config


About policy-based and route-based VPN gateway
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-connect-multiple-policybased-rm-ps?WT.mc_id=Portal-Microsoft_Azure_HybridNetworking#about


So this time we want to create a policy-based VPN S2S IPSec Tunnel.

Azure support for policy-based VPN
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-connect-multiple-policybased-rm-ps?WT.mc_id=Portal-Microsoft_Azure_HybridNetworking#azure-support-for-policy-based-vpn


As you can see the policy-based vpn gateway in Azure only supports IKEv1.


If you choose policy-based for the VPN type below you have anyway no choice regarding the different SKUs, in this case only Basic is available!

In case you choose route-based, you can choose between the SKUs VpnGw1 – VpnGw5 and VpnGw1AZ – VpnGw5AZ.

Update Oct 2023
As of Oct 1, 2023, you can’t create a policy-based VPN gateway through Azure portal. All new VPN gateways will automatically be created as route-based. If you already have a policy-based gateway, you don’t need to upgrade your gateway to route-based. You can use Powershell/CLI to create the policy-based gateways.

Source: https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-vpn-faq#why-cant-i-specify-policy-based-and-route-based-vpn-types



As we know from the last time, deployment of the Virtual Network Gateway can take up to 45 minutes! So grab a coffee and relax ☕ …





Create the Local Network Gateway

A Local network gateway represents your onPrem VPN Gateway in Azure. It is a specific object in Azure to provide some informations of your onPrem Gateway like IP address and Prem subnets you want to route over this Tunnel.

Each virtual network can have only one virtual network gateway, but one virtual network gateway can be used to configure multiple VPN connections.

Connect Azure VPN gateways to multiple on-premises policy-based VPN devices using PowerShell
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-connect-multiple-policybased-rm-ps


So we must add a local network gateway.



We need to provide the public ip address from our onPrem VPN Gateway and our local onPrem network address space we want to route over this S2S IPSec VPN Tunnel.

Because this time we configure a policy-based VPN we do not need to check Configure BGP settings


Now we an create the IPSec tunnel under the Local network gateway object and here in Settings – Connections.


To create the IPSec Tunnel in Azure we need to select the previously created Virtual Network Gateway and our Local Network Gateway. Further we need to provide a Shared key (PSK) which is used to encrypt the connection between both peers. You can let pfSense create one and provide this key here.

Note that only IKEv1 protocol is supported with policy-based gateway connections and only the SKU Basic.



If you anyway try to use IKEv2 you will get an error


Under Status you will see Unknown or Connecting. We want to see the Status Connected, but therefore we first need to configure the IPSec Tunnel at pfSense in our onPrem network.


Note that even if the pfSense Tunnel is ready configured and pfSense status is connected and traffic flow works between both peers, it can take up a couple of minutes till the Status in Azure switched to Connected.



Meanwhile we will have the following objects in our new resource group which all needed for our IPSec VPN Tunnel.





Configure the IPSec Tunnel on PfSense onPrem

To configure the IPSec Tunnel with all the correct IPSec/IKE parameters on the onPrem VPN device in your local network, there are two options available.

One is to download a configuration script from the local network gateway overview page in Azure if your device is supported and a script is available.


To see if for your device a script is available you can check this on https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices#devicetable

A detailed instruction of how to download and configure the script you will find on https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-download-vpndevicescript

For pfSense there is no script available and its also not validated by Microsoft, doesn’t matter 🙂 , it works smoothly with pfSense.

So to get all the correct IPSec/IKE paramters to set up the Tunnel in pfSense, we can look on https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices#ipsec for them.

The public IP of the Azure VPN peer you will find on the overview page from the virtual network gateway page or from the local network gateway page under the Settings – Connections menu and there when you click on your S2S connection.

The tables below contain the combinations of algorithms and parameters Azure VPN gateways use in default configuration. For route-based VPN gateways created using the Azure Resource Management deployment model, you can specify a custom policy on each individual connection. Please refer to Configure IPsec/IKE policy for detailed instructions.

Custom IPsec/IKE policy only works on the following gateway SKUs:
https://docs.microsoft.com/en-us/azure/vpn-gateway/ipsec-ike-policy-howto#considerations

Further Microsoft says regarding TCP MSS:
In addition, you must clamp TCP MSS at 1350. Or if your VPN devices do not support MSS clamping, you can alternatively set the MTU on the tunnel interface to 1400 bytes instead.

By default pfSense uses for MSS 1400, you can change it under VPN – IPSec – Advanced Settings. Here you can check Enable Maximum MSS and set it to 1350.

In my lab evironment the connection is much more stable with the default TCP MSS 1400, so I would test both values.

https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/advanced-ipsec-settings.html


In the following tables:

  • SA = Security Association
  • IKE Phase 1 is also called “Main Mode”
  • IKE Phase 2 is also called “Quick Mode”




As mentioned above, for route based VPNs with the following gateway SKUs, you can adjust the IPSec/IKE parameters to meet your requirements of the onPrem Gateway.

  • VpnGw1 – 5
  • VpnGw1AZ – 5AZ
  • Standard and HighPerformance



In this case you can adjust the parameter directly at the connection from the local network gateway under Configuration as follows:

As for policy based vpn at the moment only the SKU Basic is available, you cannot to adjust the parameter here and have to use the default from Azure on your onPrem Gateway.

Back on the pfSense I first added a dedicated public IP address under Firewall – Virtual IPs as IP Alias to use for the IPSec tunnel with Azure.


Now to set up the tunnel we navigate to VPN – IPSec – Tunnels on pfSense.

First we need to add an IKE phase 1 which authenticates the IPSec peers and set up a secure channel between the peers to enable IKE exchanges. IE phase 1 performs the following functions:

  • Authenticates and protects the identities of the IPSec peers
  • Negotiates a matching IKE SA policy between peers to protect the IKE exchange
  • Performs an authenticated Diffie-Hellman exchange with the end result of having matching shared secret keys
  • Sets up a secure tunnel to negotiate IKE phase 2 parameters

more about IKE at https://www.ciscopress.com/articles/article.asp?p=25474


Further we need to create an IKE phase 2 which is negotiate IPSec SAs to set up the IPSec tunnel. IKE phase 2 performs the following functions:

  • Negotiates IPSec SA parameters protected by an existing IKE SA
  • Negotiates IPSec SA parameters protected by an existing IKE SA
  • Periodically renegotiates IPSec SAs to ensure security
  • Optionally performs an additional Diffie-Hellman exchange

more about IKE at https://www.ciscopress.com/articles/article.asp?p=25474


At Mode is set by default Tunnel IPv4 which will be right in almost all cases and also for our policy-based vpn. For a routed-based vpn you must choose here Routed (VTI). The Mode Transport will encrypt all traffic between the endpoints rather than tunneling specific interesting internal traffic.

Add for each Subnet in your local network you want to connect to your Azure VNet and Subnet a separate Phase 2.


In pfSense you can check the Status of the VPN Tunnel under Status – IPSec – Overview

In my case I have three subnets including the perimeter network which I will tunnel through the Azure VNet subnet 172.16.10.0/24.



And now also in Azure the Status is at Connected.


If you click on the connection you can check the amount of inbound and outbond traffic.





Manage the VPN Gateway with PowerShell

You can also use PowerShell to administrate the Azure VPN Gateway.

First login to the Azure CLI with the az comman



az network vnet-gateway
https://docs.microsoft.com/en-us/cli/azure/network/vnet-gateway


az network vnet-gateway list -g MyResourceGroup


az network vnet-gateway list-advertised-routes -g MyResourceGroup -n MyVnetGateway –peer 23.10.10.9



Troubleshooting

Troubleshooting IPsec VPNs

Due to the finicky nature of IPsec, it isn’t unusual for trouble to arise. Thankfully there are some basic (and some not so basic) troubleshooting steps that can be employed to track down potential problems.

More you will find under https://docs.netgate.com/pfsense/en/latest/troubleshooting/ipsec.html


Duplicate IPsec SA Entries

In certain cases an IPsec tunnel may show what appear to be duplicate IKE (Phase 1) or Child (Phase 2) security association (SA) entries.

After lengthy testing and research, the main way this starts to happen is when both sides negotiate or renegotiate simultaneously. If both peers initiate, reauthenticate, or rekey Phase 1 at the same time, it can result in duplicate IKE SAs. If both peers rekey Phase 2 at the same time, it can result in duplicate child SAs.

Mitigating this problem involves ensuring that the chance of simultaneous negotiation is minimized or eliminated. The easiest way to reach that goal is to set higher Phase 1 and Phase 2 lifetimes on one peer, or at least make sure both sides are not set identically.

Source: https://docs.netgate.com/pfsense/en/latest/troubleshooting/ipsec-duplicate-sa.html



Set up IPSec route based S2S VPN for AWS and Google’s Cloud VPC

If you are also interested about how to set up the same for Amazon’s AWS VPC, you can read my following post.

Set up IPSec route-based S2S VPN between pfSense and AWS VPC



For Google’s Cloud VPC you can read my following post.

Set up IPSec route-based S2S VPN between pfSense and Google Cloud VPC





Links

Set up alerts on resource log events from VPN Gateway
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-set

Troubleshoot Virtual Network Gateway and Connections using Azure Network Watcher Azure CLI
https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-troubleshoot-man

Connect Azure VPN gateways to multiple on-premises policy-based VPN devices using PowerShell
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-connect-multiple-policybased-rm-ps