Thursday, November 9, 2023

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

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

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 – static routing (Part 2)
  3. 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. Azure Virtual WAN VPN Gateway 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

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.

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. You do not need them.

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. Remember, in the OPNsense appliance, a policy-based VPN is limited to one connection.

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

Link connection 1

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.

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.

  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 *

Firewall, Rules, WAN

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.

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

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

Advanced Options

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.

Phase 2 - Advanced Options. General information

Results

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

Status Overview

Also, check the Security Association Database.

Security Association Database

Now look at the security policy Database.

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.

Ping from Azure to on-prem and from on-prem to Azure

If you have other issues, check the logs and double-check all settings on the OPNsense and Azure side.

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.

 

Related materials:



from StarWind Blog https://bit.ly/3Qvl0Oj
via IFTTT

No comments:

Post a Comment