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 (Part 2)
- Route-based with BGP OPNsense Site-2-Site VPN (Part 3)
In part 1, I showed you how to configure a policy-based site-to-site VPN between Azure and OPNsense. You are now reading part 2, where I show how to set up a route-based site-to-site VPN (static routing) between Azure and OPNsense. The route-based site-to-site VPN setup with BGP (dynamic routing) is for part 3.
Often, your best site-to-site VPN option to Azure is route-based with static routing. So, yes, without BGP. First, static routes work well in smaller networks, where you can forgo the added complexity of dynamic routing protocols. Second, we control every route allowed and can customize it to lock down network connectivity to the essential traffic needed and nothing more. Also, in part 3, you notice that not every firewall optimally supports active-active tunnels with one appliance without some extra caveats to take care of, which impact failover speed and experience by the clients.
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. I 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.
Note: I have changed the actual public IP addresses used in the article for the screenshots, and where those IPs are visible in screenshots, I have masked them.
- x.x.x.x = Public IP Instance 1 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
If you have read part 1, this is a repeat for you. You should not skip this section if you are only interested in route-based setup and haven’t read part 1.
For this post, 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. You can add more than one network for a route-based setup, so there is no need to cover the entire network scope in one prefix.
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. Those are optional here.
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. You can add multiple ranges here to control what routes are available. You match those in the on-premises route configuration or use network prefixes that contain what is in your list here.
For the link connection settings, you 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 VPN firewall on-premises. We 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 via static 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. 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 have read part 1, this is a repeat for you. You should not skip this section if you are only interested in route-based setup and haven’t read part 1.
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.
OPNsense firewall rule to allow IPSec traffic from Azure
We must add an extra firewall rule to the IPSec interface for route-based traffic to flow from Azure to on-premises. Navigate to Firewall/Rules/IPSec. Add a rule to allow traffic from your Azure network, 10.180.0.0/16 in this example, to your on-prem network, VLAN2 net. You can use an alias to group IPs/networks to keep your rules manageable. But this is a simple lab example.
Remember this, or traffic originating from Azure cannot reach your OPNsense local network.
Route-based OPNsense Site-2-Site VPN Setting
I now discuss configuring OPNsense with a route-based site-to-site VPN leveraging static routing. So, not with BGP.
I already configured the OPNsense firewall to allow IPSec from Azure. Also, in Azure, I configured a non-BGP-based VPN site with a link configured to leverage static routing via BGP.
First, if you have any policy-based phase 1 VPN tunnels to your VPN gateway, deactivate those. Doing so avoids conflicting settings, not to mention confusion. You could also delete them.
In OPNsense, navigate to VPN/IPsec/Tunnel Settings [legacy] and create a new Phase 1 entry using the + button. Alternatively, duplicate the policy-based one and start from there. Fill out or change the information as shown below. Green are values I changed, and you can use them. Purple means you MUST replace it with the values for your environment.
Again, 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. For full redundancy, you need a second OPNSense appliance, but that is beyond the scope of this article.
Phase 1
Phase 1 – General Information
Disabled: unchecked (Disable this phase1 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: RB – Phase 1 – Instance-0 – AzVWAN
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: unchecked
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
Make sure to UNCHECK the “Install policy” option. We use routes, not policies, so you cannot enable this here.
The screenshot below is for your reference.
Phase 2
Phase 2 – General information
Disabled: unchecked
Mode: Route-based
Description: RB – Phase 2 – Instance 0 – Azure VWAN
Phase 2 – Tunnel network
Local Address: 172.16.16.12
Remote Address: 172.17.17.12
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
We use private IP addresses, which we don’t use for anything else anywhere, for the local and remote addresses in the tunnel network. You have two, one for instance 0 and another for instance 1. We keep those final octets matched to the one used in the OPNsense Gateway configuration and descriptions to avoid confusion.
The screenshot below is for your reference.
We have completed the VPN tunnel setup for Instance 0. We need to finish the rest of the OPNsense configuration to make route-based VPN work.
Set MSS size
Under Interfaces for your automatically created IPSec interface, set the MSS value to 1350. Remember this. Leave all the other settings on their default value.
MSS stands for Maximum Scale Size. See https://docs.opnsense.org/manual/firewall_scrub.html for more information.
The screenshot below is for your reference.
Add the gateway for your VPN tunnel’s interface
Add a new gateway with the following configuration in OPNSense under System/Gateways/Single.
Name: RB-VPN-GW-TO-AZURE-Instance-1
Description: Gateway to route traffic for Azure via Instance 0
Interface: RBPhase1Instance0AzureVWAN
Address Family: IPv4
IP address: 10.250.250.12
Upstream Gateway: unchecked
Far Gateway: checked
Disable Gateway Monitoring: checked
Disable Host Route: unchecked
Monitor IP: empty
Mark Gateway as Down: unchecked
Priority: 255
Advanced: We leave this at the default for now
Note a couple of things:
- First, note that the interface’s name is created for you when the VPN tunnel is enabled.
- The IP address (10.250.250.12) is that of the Azure VPN Gateway Instance 0, the private one, not the public one.
- You must check Far Gateway to enable it, allowing the gateway to exist outside the interface subnet.
The screenshot below is for your reference.
Add a static route to the Azure address space(s) via the gateway
Now that you have a gateway to the IP address of your Azure VPN gateway instance 0 set up, you can add one or more static routes so the traffic to Azure knows where to go.
Under System/Routes/Configuration, add a route as follows
Disabled: unchecked
Network Address: 10.180.0.0/16
Gateway: RB-VPN-GW-TO-AZURE-Instance-0 – 10.250.250.12
Description: Routes Traffic for 10.180.0.0/16 (Azure) via the GW for Instance 0
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.
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 are curious about how the policies for route-based VPN tunnels look, check the Security Association Database.
Take a peek at the security policy Database as well.
OPNsense created these for you. All you had to provide were the gateways and the static routes.
As before, most components have logging, so if you have other issues, check those logs and double-check all settings on the OPNsense and Azure side.
With two tunnels set up for the active-active Azure site-to-site VPN tunnels, verify failover by testing. Disable one active VPN tunnel. You should see a couple or more dropped pings, but communication should all flow over the remaining active tunnel. Do note the GUI bug with the IPSec interface mentioned above. That could be confusing when looking at your settings.
Conclusion
I have shown you how to configure a route-based site-to-site VPN In OPNsense to an Azure VWAN VPN Gateway. In part 1, you can learn about policy-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 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.
