Search
StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge

OPNsense Site-2-Site VPN to Azure VWAN Configuration – Part 2

  • November 23, 2023
  • 27 min read
Cloud and Virtualization Architect. Didier is an IT veteran with over 20 years of expertise in Microsoft technologies, storage, virtualization, and networking. Didier primarily works as an expert advisor and infrastructure architect.
Cloud and Virtualization Architect. Didier is an IT veteran with over 20 years of expertise in Microsoft technologies, storage, virtualization, and networking. Didier primarily works as an expert advisor and infrastructure architect.

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.

 

OPNsense logo

 

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:

  1. Policy-based OPNsense Site-2-Site VPN (Part 1)
  2. Route-based OPNsense Site-2-Site VPN (Part 2)
  3. 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.

Route-based OPNsense

The above implements what Microsoft describes in About Highly Available gateway configurations – Azure VPN Gateway under Active-active VPN gateways.

Diagram shows an on-premises site with private I P subnets and on-premises VPN connected to two active Azure V P N gateway to connect to subnets hosted in Azure.

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.

Edit VPN site

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.

Edit link

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.

Edit VPN connection

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).

For the link connection settings, you notice that BGP is disabled

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.

Download 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.

  1. Protocol ESP from Azure VPN GW public IP addresses to local gateways *
  2. UDP Traffic on port 500 (ISAKMP) from Azure VPN GW public IP addresses to local gateways *
  3. UDP Traffic on port 4500 (NAT-T) from Azure VPN GW public IP addresses to local gateways *

OPNsense firewall settings for IPSec

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.

Navigate to Firewall/Rules/IPSec

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 - General Information

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 (Authentication)

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 - Proposal (Algorithms)

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 1 - Advanced Options

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.

Phase 2 - Advanced Options

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.

IPSec interface

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 the gateway for your VPN tunnel's interface

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.

Add a static route to the Azure address space(s) via the gateway

Results

When you configured everything correctly on both sides, in OPNsense and Azure, you should see the tunnel come up.

VPN/IPsec/Status Overview

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.

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.

Security Association Database

Take a peek at the security policy Database as well.

Security Policy Database

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.

Hey! Found Didier’s article helpful? Looking to deploy a new, easy-to-manage, and cost-effective hyperconverged infrastructure?
Alex Bykovskyi
Alex Bykovskyi StarWind Virtual HCI Appliance Product Manager
Well, we can help you with this one! Creating a hyperconverged environment is a breeze with StarWind Virtual HCI Appliance (VHCA). It’s a complete hyperconverged infrastructure solution that combines hypervisor (vSphere, Hyper-V, Proxmox, or our custom version of KVM), software-defined storage (StarWind VSAN), and streamlined management tools. Interested in diving deeper into VHCA’s capabilities and features? Secure your personalized StarWind Virtual HCI Appliance demo today!