Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - user290920

#1
High availability / Using Gateway Group for HAProxy
October 01, 2025, 06:15:12 PM
I've put this in here because it involves using Gateway Groups and CARP.

I have an HA cluster of two (2) OPNsense servers that sits in front of two (2) HAProxy servers. In an effort to keep everything clean, the HAProxy servers are VMs separate and apart from OPNsense. I want to create a VIP where traffic to that VIP is routed by OPNsense to the HAProxy servers, providing they pass their health check (i.e. a simple PING test).

After bit of research I've found some information on the web suggesting that a can create using a Gateway Group + Firewall rules in OPNsense that would route the TCP request to the HAProxy server, providing they pass their PING health check. Has anyone had any suggest with something like this? And, if not this approach, what would you recommend?

I cannot install/enable HAProxy on the OPNsense firewalls, unfortunately. Received a hard "no" from the team.
#2
This was fixed after upgrading both OPNsense firewalls to v25.7.
#3
I am running into a similar problem running OPNsense 24.7.12_4-amd64.

The fix for me is to go into log back into the desired MASTER, go to Interfaces > Virtual IPs > Status then toggle both buttons, i.e. `Temporarily Disable CARP` and `Enter Persistent CARP Maintenance Mode`. That resets the `Current CAP demotion level` back to zero (0) and the desired firewall becomes the MASTER again.

If not, the BACKUP remains the MASTER indefinitely.
#4
If anyone else runs into this problem where you are creating a cluster for the first time by adding an additional FW into your OPNsense network, the "Identifiers" for the interfaces must match. e.g. `VLAN X` must have `opt1` on both OPNsense firewalls.
#5
Hi Everyone,

I have an existing network, multiple VLANs and firewall rules, etc. I am trying to add a 2nd OPNsense firewall. The 2nd OPNsense firewall has its own dedicated internet connection from a separate ISP. I have two (2) goals: a) Make OPNsense fault tolerant. i.e. If `FW1` goes down, `FW2` will take over. And, b) Make our WAN highly available. So if `ISP1` (exclusively connected to `FW1`) goes down, internet will route through `ISP2` (exclusively connected to `FW2`). More details about my configuration can be found here.

Whilst I can appreciate the recommendation is to start fresh with two (2) new OPNsense firewalls, and recreate "everything" together on each OPNsense server; I don't have two (2) machines laying around. Thus, I am stuck with my current situation where I am trying to "add" this 2nd firewall into the existing network, configure OPNsense in HA, and make the necessary changes to the downstream networks. Because I'd imagine there must be a lot of people in that same situation, I figured I'd post here.


We've ran into a situation where I noticed that CARP traffic from the default gateways in the various subnets are trying to traverse across VLANs. I think I've discovered that's due to there being a mismatch on the "Identifiers" (under Assignments) on each firewall. For example, on `FW1`, Identifier `opt1` is pointing to "Network A". And on `FW2`, Identifier `opt2` is pointing to "Network C". That happened because we manually defined the Assignments in a different order on FW2, then we did when we initially setup FW1.

So to avoid me discovering any other important configuration like this "the hard way", does anyone know of a checklist or guide that walks through adding a 2nd OPNsense firewall into an existing network? And, if no guide exists, does anyone here with this sort of experience have any advice on what else I need to check or watch out for?
#6
Forgive me, and allow me to rephrase my question.

If ISP1 where to go down (and FW1 remains up), is it possible for OPNsense to route internet over ISP2, even though ISP2 is exclusively plugged into FW2?
#7
Excellent. Thank you for the reply.

So, in my case ISP1 is connected to FW1. And, ISP2 is connected to FW2.

If ISP1 were to go down, is it possible to failover to FW2 and ISP2, even though FW1 is still up?
#8
Hi Gents,

I have two OPNsense firewalls on hardware that only has two physical NICs. I have two internet connections, each internet connection connected to one firewall.

There's no option to add an additional NIC to the firewalls, unfortunately. The goal is to eventually replace the firewalls with more suitable hardware. But that's a project for 6-12 months from now. My goal is an OPNsense in a high availability cluster. I want to be able to take a firewall down for patching, and firewall and internet will failover to the 2nd OPNsense firewall.

All of the OPNsense HA tutorials assume a 3NIC configuration. Can I accomplish the same on a 2NIC configuration? The setup is as follows:

My thoughts were that FW1 & FW2 would each have NIC1 dedicated to the WAN. NIC2 would be connected to an unmanaged switch, where I would use VLANs to split LAN and CARP traffic. What's your thoughts about this configuration? Possible? Would you make any changes? What would they be?
#9
I explored that option, but decided not to go that route. Didn't like the idea of multiple HAProxy server (potentially running at different versions). And, trying to keep my OPNsense server as "clean" as possible, with only the core services running on it.

Anyone else, please?
#10
We have OPNsense sitting between our internal network and the Internet. Once allowed through OPNsense, inbound web requests coming in from the Internet to our web servers are proxied by 2x HAProxy servers. Is there a way to get OPNsense to perform regular "Healthcheck" monitors to the HAProxy servers to ensure that the servers are healthy, and prepared to serve requests? Ideally OPNsense should perform regular HTTP requests, and close the path to the faulting HAProxy server (e.g. http://ip.to.haproxy.server/I/am/healthy). But, at this point, I'll settle for a simple PING test.

Forgive me if this is obvious, but I haven't found anything after 2HRs of searching...
#11
If you are a n00bie like me, and are coming across this article... I figured it out. Below are the steps:
As for forum moderators and OPNsense developers, I think it would be helpful if within your documentation you emphasised that OpenVPN Access Server is an easy option for organisations looking to implement a MFA-protected VPN solution. IMO everything on the web points to using OpenVPN embedded into OPNsense, making organisations think that authentication via RADIUS and LDAP are the only options.

Personally, for VPN I think it is safer to limit the number of times end-users need to enter their username/password. Instead, each time they access they should complete a push/biometric challenge. Since re-authentication is so much faster, you can make your VPN disconnect after a few minutes of inactivity. And, end-users can't really complain since reconnecting is so simple. OpenVPN AS as a FREE license that allows 2 concurrent connections. After that you have to purchase a subscription, which is reasonable, all things considered.
#12
We have replaced our Fortinet FW with OPNsense. One of the outstanding things is get VPN back up and running. With the Fortinet VPN we were using SAML for Authentication, and I'd really like to continue to do that for ease of use by our end-users. It seems like we need to implement OpenVPN Access Server to have SAML authentication (source).

I've scoured the internet for the past 2HRs, no luck finding a guide for deploying OpenVPN Access Server and configuring it to work with OPNsense. Can someone please refer one for me?

Also, if we deploy OpenVPN Access Server, can we still configure an a Site-to-Site IPSec VPN *on OPNsense*? Or, does configuring the OpenVPN Access Server disable the OPNsense Site-to-Site VPN feature and offload all VPN to OpenVPN Access Server?

Ideally, I would like Site-to-Site to be done through OPNsense. And, end-users to VPN using OpenVPN Access Server, authenticating using SAML authentication.