Introduction
I share three site-to-site VPN configurations in OPNsense to an Azure (Virtual WAN) VPN Gateway in this three-part series. I often need a firewall for testing and lab work to validate my designs in a more realistic environment and set up VPNs for cloud providers. Proprietary firewalls are expensive, and most of the time, you cannot update them without a paid subscription or when the device model is “end of life,” which means it is no longer supported and receives no more updates. That is why I run OPNsense in my labs. You can download the open-source OPNsense ISO’s here. I run it on a Hyper-V, which works very well. OPNsense provides me with a cost-effective and capable firewall in the lab or in production where applicable.
Types of VPN site-to-site configurations
There are three main site-2-site IPSec VPN configurations we can set up with OPNsense and Azure Virtual WAN:
- Policy-based OPNsense Site-2-Site VPN (Part 1)
- Route-based OPNsense Site-2-Site VPN – static routing (Part 2)
- Route-based with BGP OPNsense Site-2-Site VPN – dynamic routing (Part 3)
You are now reading part 1, where I show how to set up a policy-based site-to-site VPN between Azure and OPNsense. Part 2 discusses configuring a route-based site-to-site VPN with static routing between Azure and OPNsense. In part 3, I look at dynamic routing with BGP.
Since setting up a site-to-site VPN to an Azure Virtual WAN can be intimidating to people new at this, I decided to share my setups with you.
In case you wonder, yes, you configure BGP on an Azure Virtual WAN VPN Gateway, which always provides two active-active tunnels. However, you can connect to a single appliance with active-active tunnels without using BGP, depending on how you configure the VPN Site itself on the VPN gateway in Azure. These are the policy-based and (static) route-based configurations. We also show you what you need to do on the Azure side to make this work. You need a second OPNsense appliance for complete redundancy, which requires using BGP. That is beyond the scope of this. Also, note that OPNsense has active-passive HA, not active-active.
Please note that I have replaced the public IP addresses in the article and the screenshots with placeholders. Where actual IPs are visible in screenshots, I have masked them.
- x.x.x.x = Public IP Instance 0 of Azure VWAN VPN Gateway
- y.y.y.y = Public IP Instance 1 of Azure VWAN VPN Gateway
- z.z.z.z = Public IP on-premises OPNsense firewall
I refer you to the image below for an overview of what we are building. 
The above implements what Microsoft describes in About Highly Available gateway configurations – Azure VPN Gateway under Active-active VPN gateways.
Image courtesy of Microsoft 1
On the Azure VWAN VPN Gateway
In this article, I do not repeat how to deploy resource groups, networking, virtual machines, an Azure Virtual WAN with a Virtual Hub, connected VNETs, and a VPN Gateway. That has been done before and well by Microsoft. See Tutorial: Create site-to-site connections using Virtual WAN. I point out the subtle difference we need to configure when creating a VPN site for policy-based or route-based site-to-site VPN versus one for routed-based with BGP, for example.
When you create a VPN site, please name it, specify the vendor as always, and provide at least one private address space. In the case of our lab for a policy-based VPN, I use just one, and I have it span all possible subnets in 192.168.0.0/16. I use multiple /24 subnets on-premises, and this covers them all. For a route-based setup, you can add additional networks. In OPNsense, a policy-based VPN is limited to one connection.
Once you have done that, you must create at least one link. Name it, provide the link provider name, and add the link speed. Finally, add your on-premises firewall’s remote IP address or FQDN (z.z.z.z on the overview image). Leave the link BGP address and the link ASN blank. You do not need them.
When connecting the policy-based VPN site to your Virtual Hub, set “Configure traffic selector” to Yes. Provide both the local address range and the remote address range. I used 10.0.0.0/8 to cover all my VNETs connected to the VPN and 192.168.0.0/16 to cover all my remote (on-premises) subnets/VLANs. Choose these network ranges according to your needs. Remember, in the OPNsense appliance, a policy-based VPN is limited to one connection.
For the link connection settings, notice that BGP is disabled. Ensure to use IKEv2 and, very importantly, enable the “Use policy-based traffic selector” setting. The latter configures the Azure VPN gateway to connect to a policy-based or route-based VPN firewall on-premises. We must ensure that OPNsense has matching traffic selectors defined with all combinations of your on-premises network (local network gateway) prefixes to/from the Azure virtual network prefixes. You can read how we do this later in this article via security policies (kernel routes) on the OPNsense device. It speaks for itself that you need to enter the correct pre-shared key (PSK).
You must take care of these details when setting up the VPN site, link, and connection to the Virtual Hub as they determine what kind of site-to-site VPN you can configure on the OPNsense appliance.
Once done, you can easily download the VPN config file from the portal.
It provides a wealth of information to help with configuring the VPN settings. You can find the public addresses for your VPN tunnel instances in that file. Information about the connected VNETs and, depending on the type of VPN sites you configured, the private IP address for your VPN tunnel instances and BGP ASN number are also there. It has everything you need to configure your VPN. In case you need to find out what ASN number you can use in Azure and on-premises, see the Azure VPN Gateway FAQ
OPNsense firewall settings for IPSec
If you made it this far in the article, you know how to install an OPNsense device. If not, grab the image and deploy it in a virtual machine to practice. There are plenty of good articles on how to do this all over the internet. Come back when you have that covered 😉.
First, we must allow IPsec tunnel connections over the OPNsense WAN interface. Add the following rules under Firewall/Rules/WAN.
- Protocol ESP from Azure VPN GW public IP addresses to local gateways *
- UDP Traffic on port 500 (ISAKMP) from Azure VPN GW public IP addresses to local gateways *
- UDP Traffic on port 4500 (NAT-T) from Azure VPN GW public IP addresses to local gateways *
Pro Tip: use an alias in which you collect all remote IP addresses that can initiate an IPSec connection to your OPNsense firewall. Since we have two active-active tunnels with Azure VWAN, reducing the number of rules to add already pays off. Maintenance is also a lot easier.
Policy-based OPNsense Site-2-Site VPN
In OPNsense, navigate to VPN/IPsec/Tunnel Settings [legacy] and create a new Phase 1 entry using the + button. Fill out the information as shown below. Green are values I changed, and you can reuse them. Purple means you MUST replace it with the values for your environment.
I show the configuration for one tunnel, instance 0, of the Azure VWAN site-to-site VPN. You should repeat the process for tunnel instance 1 to get failover/redundancy during maintenance in Azure.
Phase 1
Phase 1 – General Information
Disabled: unchecked (Disable this phase 1 entry)
Connection method: Start immediate
Key Exchange version: V2
Internet Protocol: IPv4
Interface: WAN
Remote gateway: x.x.x.x
Dynamic gateway: unchecked (Allow any remote gateway to connect)
Description: PB – Phase 1 – Instance-0 – Azure VWAN
The IP address for the Remote gateway, x.x.x.x, is the Azure VPN Gateway – Instance 0 Public IP. Setting up Instance 1 is an exercise for the reader where you need to use the IP address of Instance 1.
The screenshot below is for your reference.
Phase 1 proposal (Authentication)
Authentication method: Mutual PSK
My identifier: My IP address
Peer identifier: Peer IP address
Pre-Shared Key: YOUR COMPLEX SHARED KEY STRING
The screenshot below is for your reference
Phase 1 proposal (Algorithms)
We use the Azure VPN gateway defaults here for encryption and hashing algorithms. These are known to work at the time of writing. Microsoft has recommendations on what is better and more performant. There is an option to customize this in the Azure site-to-site VPN settings. I leave that as an exercise for the reader and for when the organization mandates it.
Encryption algorithm: AES
256
Hash algorithm: SHA256
DH key group: 2 (1024 bits), 14 (2048 bits)
The screenshot below is for your reference
Phase 1 – Advanced Options
Install policy: checked
Disable Rekey: unchecked
Disable Reauth: unchecked
Tunnel Isolation: unchecked
SHA256 96 Bit Truncation: unchecked
NAT Traversal: Disable
Disable MOBIKE: unchecked
Close Action: None
Unique: Replace
Dead Peer Detection: checked
10 seconds
5 retries
Restart the tunnel DPD action
Inactivity timeout
Inactivity timeout: unchecked
Keyingtries: empty
Lifetime: 28800
Margintime: empty
Rekeyfuzz: empty
Take Note
Take note that I checked the “Install policy” option. It installs the IPsec policies in the kernel ( a”kernel route”) by the charon daemon (strongSwan, see Virtual Private Networking — OPNsense documentation)for the given connection. Without it, OPNsense cannot intercept traffic for the Azure network and send it to the IPSec tunnel before regular routing happens and decides to blackhole the traffic as it has no route. Yes, it is called a policy-based site-to-site VPN for a reason.
The screenshot below is for your reference.
Phase 2
Phase 2 – General information
Disabled: unchecked
Mode: Tunnel IPv4
Description:
Local Network
Type: Network
Address: 192.168.0.0/16
Remote Network
Type: Network
Address: 10.180.0.0/16
Phase 2 proposal (SA/Key Exchange)
Protocol: ESP
Encryption algorithms: AES256
Hash algorithms: SHA256
PFS key group: off
Lifetime: 28800 (seconds)
Phase 2 – Advanced Options
Automatically ping host
Manual SPD entries: empty
I use “Network” for Local Network because it allows me to subnet the private IP block to scope over multiple VLANs/Subnets in my on-premises lab. Had I selected a specific VLAN, my connectivity to Azure would have been limited to that subnet.
The screenshot below is for your reference.
Results
When you configured everything correctly on both sides, in OPNsense and Azure, you should see the tunnel come up.
Also, check the Security Association Database.
Now look at the security policy Database.
If all is well, you should see the security policies required for this site-to-site VPN to work there. Note that you only see the security policies for a single tunnel, but that is fine. Failover is very fast. It drops a ping or two at most.
TIP:
When you see the above image but only incoming traffic in “Bytes in,” and you can’t get a ping to respond, the most likely cause is that you forgot to enable “Install Policy” in Phase 1 Advanced options. Remember, we emphasized earlier that we cannot route traffic without a policy (kernel route). That intercepts traffic on the OPNsense we want to route to Azure via the IPSec VPN.
If you did everything correctly, traffic should be flowing in both directions between Azure and your OPNsense local network over your route-based VPN site-to-site tunnels. You can see the ping from Azure to on-prem in the white font command prompt and from on-prem to Azure in the red font command prompt.
If you have other issues, check the logs and double-check all settings on the OPNsense and Azure side.
Play around when things are working. If you turn off one active VPN tunnel, you should see a couple or more dropped pings, but communication should all flow over the remaining active tunnel.
Conclusion
I have shown you how to configure a policy-based site-to-site VPN In OPNsense to an Azure VWAN VPN Gateway. In part 2, you can learn about route-based configuration, and in part 3, I discuss route-based with BGP. It can initially seem daunting, but once you test the concepts in the lab, you soon learn to configure, test, and troubleshoot such setups. I use OPNsense in the lab as it gets frequent updates and has a clean, easy-to-follow user interface. The benefit OPNsense has over Microsoft RRAS is that it also has a firewall. Learning about configuring firewalls and routing using OPNsense is excellent for educational purposes. The experience prepares you for configurations you’ll encounter in your work.
In my experience, an OPNsense VPN to Azure works very well and is stable. You can buy OPNsense hardware and support, but nothing keeps you from installing it on one or two spare DELL Servers with 1-/25/50/100Gbps Mellanox cards. That exercise helps you determine how well it can scale before you commit your money. Meanwhile, learn how to use the product on virtual machines.
