.matrixpost

Marcus Rath

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

Today I want to go over the steps to establish a Site-to-Site vpn tunnel between an onPremise network and a virtual network (VNet) in Azure. At onPremise site the gateway will be a pfSense appliance in version 2.4.4-p3.

First we have to create a virtual network in Azure which we will be later connected over a S2S vpn tunnel with our onPremise network.

Inside this VNet we create an subnet in which our virutal machines will reside and therefore be connected over the vpn tunnel with our onPremise network.

As we create a dynamic route based S2S vpn tunnel, I will add a further address space to the VNet. I don’t really need this but we can see later how these several address spaces will be automatically advertised by the BGP protocol and so we do not have to create hidden policy-based forwarding rules with several phase 2.

As mentioned we do not need to add an IKEv2 phase 2 for each subnet which should be tunneled over the vpn connection, instead we only need one phase 2 for the transit network, over this all subnets will be routed through the tunnel.

Next we have to add a gateway subnet to the VNet, in this subnet resides the ip addresses of the virtual network gateway which we create later. 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.

Now we create a virtual machine so that we later can test the vpn tunnel with it. If we create the vm in the same resource group as the VNet, in this case braintesting.de, then the vm will be automatically given an ip address from our previous created VNet and subnet 172.26.10.0/24.

We do not add a network security group to the vm so that we later can easily test different protocols over the vpn tunnel and do not have to configure allow rules. Therefore the vm becomes no public ip address and we only access the vm over the vpn tunnel.

To connect our VNet with the onPremise network we need to create a Virtual Network Gateway in Azure.

The Virtual Network Gateway are two or more virtual machines which will be created in our previous created GatewaySubnet. These virtual machines provides routing tables and services for the gateway.

For the Gateway type we use VPN and the VPN type is Route-based.

Because we creat a Route-based VPN which determines dynamically the routes, we must enable and configure here the BGP protocol. For the Azure site is the private ASN 65515 reserved.

https://en.wikipedia.org/wiki/Autonomous_system_(Internet)

In my case I get a wired error message at validation that the ASN 65515 is reserved for Microsoft and cannot be used ? , after retyping the number 65515 the validation passed, no idea why this happens, must be a bug at the moment.

The deployment of the Virtual Network Gateway can take up to 45 minutes! So grab a coffee ☕ …

Here you can see the finished Virtual Network Gateway, under Settings – Configuration you can see the BGP peer IP which we need later for the vpn configuration at pfSense.

Next we have to create the Local Network Gateway which will connect the Azure subnets with our onPremise subnets over the Virtual Network Gateway.

Under IP address you must use the public IP address from pfSense on the onPremise network. In my case 62….

Under Address space we type the IP from our BGP peer in pfSense. This is the IP from the internal interface from pfSense. Also we type this IP in the BGP peer IP address field below.


The last step to configure in Azure, the actual IPSec Connection, we first create at the pfSense in the onPremise network the IPSec tunnel, Border Gateway Protocol and the transit network.

First we install with the Package Manager the OpenBGPD daemon, which will provide us the BGP Protocol at pfSense.

After installation of OpenBGPD we can configure it under Services – OpenBGPD – Settings.

For the ASN Number I use the private 65505 which we previous set at the Local Network Gateway in Azure. For the Listen and Router IP I use the internal IP from the pfSense Interface.

https://en.wikipedia.org/wiki/Autonomous_system_(Internet)

At Network you can select which networks should be advertised to the VNet in Azure. I used here inet static which advertises the static routes on the pfSense.

Be aware of adding the inet connected to the advertised networks, both networks from the local adapters (WAN/LAN) will be advertised as route to the Azure BGP peer.

In this case, also the complete WAN Subnet in which the adapter resides, will be advertised as route to the Azure BGP peer.

Because of this, all interfaces in this VNet will get this route included in their routing table.

Therefore the VMs would try to reach all public IPs from this Subnet, through the vpn tunnel instead the default gateway for the internet traffic, which would be not desirable and working.

At the Groups tab we set the ASN from the Azure VNet which will be our remote site.

Last for the BGP configuration we must add the BGP Neighbor. Set here the BGP Neighbor IP from the Azure BGP peer. You find this IP in Azure under the settings from the Virtual Network Gateway and is in my case the 172.16.1.30. Under Groups select the previous created remote ASN Group from Azure.

Under Raw Config you can review the complete BGP configuration.

The tab Status we will examine later, first we have to configure the IPSec tunnel.

So select from the menu VPN – IPSec and first create a Phase 1.

Under Key Exchange Version select IKEv2 which will use Azure. As Remote Gatway we use the public IP from the Azure Virtual Network Gateway which you will find in the overview of it.

As Pre-Shared Key (PSK) we will let pfSense create one for us.

Now as we finished Phase 1 we can create the Phase 2. As we create a Route-based VPN we only need one Phase 2 for the transit network over this our local subnets will be routed to Azure. If we would create a Policy-based VPN, we had to create for each subnet we want to route over the Tunnel, a Phase 2.

Therefore you must select at Phase 2 Mode Routed(VTI). VTI stands for Virtual Tunnel Interface. The default setting is Tunnel IPv4 for Policy-based VPN.

As you select the Routed(VTI) Mode, at pfSense is created a further interface which we will see and assign later.


After selecting Routed(VTI) under Local Network, this will be automatically set to Network with a Subnet Mask of /30 which can contain 2 IP addresses. This Network will be our transit network over them the local subnets will be routed to Azure and vice versa.

Because the BGP peer IP from Azure is the 172.26.1.30 and we have a /30 subnet for the transit network wich contains two ip addresses, we must set at pfSense for the Local Network the IP 172.26.1.29/30 and under Remote Network the BGP peer IP from Azure with 172.26.1.30.

After this we had created the transit network wich will be represented through the Phase 2 and will be used to route our local subnets through this tunnel.

As we finished the creation of the IPSec tunnel in pfSense we now have to create it also in Azure.

Therefore we go to the Azure Portal and the Local Network Gateway. Under Settings select Connections.

Under Virtual Network Gateway we select the previous created VpnGW-braintesting.de and under Shared key (PSK) we copy and paste the PSK which was generated from pfSense.

After selecting the connection, we can go to the overview and download the configuration from the IPSec tunnel. Here you can see the used parameters and settings for the Phase 1 and Phase 2 which we must use in pfSense also.

In pfSense under Status – IPSec, we see that the VPN tunnel is successfully established. In the Azure Portal it can last some minutes till you can see the status connected.

A few minutes later …

That routing in pfSense finally works over the IPSec tunnel, we have to assign the IPSec Interface (VTI) which was automatically created after set the Tunnel Mode to Routed(VTI) in the Phase 2 settings.

Therefore go to the menu Interfaces – Assignments and add the ipsec Interface.

After the assignment you will find this interface with the name OPT1. I changed the name to IPSecVTI for a better understanding.

Per default the interface is not enabled, so don’t forget to enable it!

As you can read, we cannot set manuel an IP Configuration. The interface will get automatically an IP from the previous created transit network. This IP will represent the gateway to reach our Azure VNet.

Under System – Routing the Interface is automatically added as Gateway.

On the Dashboard of pfSense we can see under Interfaces the IPSec Interface and his IP.

Now we will take a look at the previous mentioned point in the menu under Services – OpenBGPD – Status. Here we can check if the BGP protocol works and if both peers pfSense and Azure exchange his routing tables with the subnets.

As we can see there is no active connection to the BGP peer in Azure.

In my case in Azure the BGP was disabled at the Local Network Gateway.

So after enabled the BGP in Azure and several minutes, the connection between the two peers was established successfully and the routing informations was exchanged between them.

Here you can see that the connection over the BGP protocol was established since 2:26 minutes between pfSense and the Azure BGP peer Neighbor and the AS number 65515.

Under OpenBGPD Routing we will see both address spaces from our Azure VNet wich will be advertised dynamically over the BGP protocol to pfSense.

Further we see the Gateway pfSense will use to route traffic for this VNet. This is the BGP peer IP from Azure.

Under OpenBGPD Forwarding we see our internal subnets from the onPremise Network and the corresponding gateway.

Under OpenBGPD Neighbors we will see the status of both peers.

Finally we must allow traffic flow from the Azure VNet to our onPremise network over the IPSec tunnel. The following rule will allow any IPv4 traffic from Azure VNet to the onPremise network. In productive business you should obviously for security reasons only allow required traffic.

Traffic flow from onPremise to Azure you control either from back firewalls in your network or on the LAN Interface at pfSense.

In Azure you can check over the CLI also the advertised routes from pfSense peer to the Azure peer:

Under https://docs.microsoft.com/en-us/cli/azure/network/vnet-gateway?view=azure-cli-latest will find an overview of CLI commands for the Virtual Network Gateway.

Leave a Reply

Your email address will not be published. Required fields are marked *