HA Cluster with a /30 CIDR for public IP

[NEOSA]

Hi all,

Is it possible to set up an OPNSense environment as a high-availability HA Cluster with the following constraints:

- Having private-addressed public interfaces, whilst the public IP address is in a /30 CIDR block?

Example: 1.2.3.4/30 as the public IP address - ISP GAteawy = 1.2.3.5/20 - As it is therefore not possible to have a public IP address per interface in the HA Cluster group on WAN-type interfaces.

Here is the planned setup below, would like opinions if it is a valid setup : thanks in advance for feedback ;-)



To set up High Availability (HA) on OPNsense (via CARP), the official documentation typically states that you need 3 IP addresses in the same subnet: one for the Master, one for the Backup, and one shared Virtual IP (VIP). With a /30 subnet (which only provides 2 usable IP addresses), this standard method is mathematically impossible.

Fortunately, there is an excellent workaround: using the "IP Alias" mode combined with private addressing on the physical WAN interfaces.

Here is how to structure this configuration.

1. The Logical Architecture (The Concept)
The trick is to configure the physical WAN interfaces of your two OPNsense nodes with private IP addresses (for example, in a dedicated /24 or /29 subnet for the interconnection with your public router/gateway), and to set up a private CARP between them.

Then, you assign your single available public IP as an IP Alias attached to this private CARP VIP.

Addressing Schema
Imagine your provider's router (Gateway) has the public IP 1.2.3.5/30 and provides you with the IP 1.2.3.6/30. For the local interconnection, we will use the private network 192.168.100.0/29.

ISP Router / Gateway: 1.2.3.5/30 (Routes traffic to your block)

WAN Interconnection Network: 192.168.100.0/29

OPNsense Master (Physical WAN): 192.168.100.1

OPNsense Backup (Physical WAN): 192.168.100.2

CARP VIP (Virtual): 192.168.100.3

Virtual Public IP (IP Alias): 1.2.3.6 (carried by the CARP VIP 192.168.100.3)

2. Configuration Steps in OPNsense
Step 1: Configure Physical IPs and Private CARP
On the Master, assign the address 192.168.100.1/29 to the WAN interface.

On the Backup, assign the address 192.168.100.2/29 to the WAN interface.

Go to Interfaces -> Virtual IPs -> Settings.

Create a new Virtual IP of type CARP:

Interface: WAN

Address: 192.168.100.3 / 29

Virtual IP Password: [Your password]

VHID: [A unique identifier, e.g., 1]

Step 2: Add the Public IP as an IP Alias
This is where the magic happens to bypass the /30 limitation.

Still in Interfaces -> Virtual IPs -> Settings, create a new Virtual IP.

Choose the IP Alias type.

Interface: WAN

Address: 1.2.3.6 / 30 (Your single public IP)

Virtual IP Association: Select the CARP VIP you just created (192.168.100.3).

💡 Why does this work? The public IP Alias will "graft" itself onto the private CARP IP. When the Master is active, it takes ownership of both the private CARP IP and the associated public IP. If the Master goes down, the Backup instantly recovers the CARP VIP and the public IP Alias.

Step 3: Configure the Gateway and NAT
In System -> Gateways -> Single, ensure that your WAN's default gateway correctly points to your ISP router's IP (1.2.3.5).

In Firewall -> NAT -> Outbound, switch the mode to Hybrid or Manual.

Modify your outbound NAT rules (or create one) so that Internet-bound traffic does not use the physical interface IP (192.168.100.x), but rather the public IP Alias (1.2.3.6).

3. Important Points of Vigilance
The Upstream Router (ISP / Switch): The router providing your /30 subnet must be capable of routing traffic destined for 1.2.3.6 toward the CARP VIP 192.168.100.3. If it is a simple Layer 2 switch or bridge, ensure that the ARP protocol resolves correctly.

Synchronization (pfsync): Do not forget to configure a dedicated interface (often called DMZ or SYNC) for state table synchronization (pfsync) and configuration synchronization (XMLRPC) between your two nodes.

"Promiscuous" Mode: If your OPNsense instances are virtual machines (VMware ESXi, Proxmox, Hyper-V), you must enable Promiscuous Mode / MAC Address Spoofing on the vSwitches of both the WAN and LAN interfaces. Otherwise, the CARP protocol will be blocked."

[viragomann]

As far as I know, the CARP VIP does not necessarily need to be within the same subnet as the interface addresses.

With this setup as it is, the backup node will have no internet access, e.g. for updates.
To enable internet you have to route its upstream traffic over the master node.

[Adriggon]

As far as I know, the CARP VIP does not necessarily need to be within the same subnet as the interface addresses.

With this setup as it is, the backup node will have no internet access, e.g. for updates.
To enable internet you have to route its upstream traffic over the master node.
This need to study technical details in depth and seek out reliable instructions arises in a wide variety of areas of life, when general advice from the internet doesn't work. For example, users of financial platforms often face similar challenges: My issue was simple: I needed an online casino that takes amex, but the answers I found in forums were inconsistent. I ended up using Interacasino.com because it had a dedicated page for American Express casino options. It gave me a clearer idea of how to compare deposit support, withdrawal methods, and possible restrictions. After reading it, I knew what to look for in the payment section before making an account anywhere.

You are absolutely correct in your assessment. A CARP virtual IP address (vIP) can indeed be located on a different subnet, but this configuration creates specific routing issues for the backup node.

[toreamun]

Your private-WAN + public-on-the-CARP-VIP approach is exactly the topology I ended up writing down for the "not enough WAN IPs for CARP" case — private per-node WAN IPs used only for CARP advertisements, with the public address floating on the VIP. So you're on a sound track.

On the backup having no internet: that's a real point, and there are two answers. Either just accept it — both nodes share one physical WAN uplink, so the backup's own internet adds no HA value (if the WAN is down, it's down for both); the backup can pull pkg/NTP/DNS/config from the master over the SYNC link. Or, if you want it, route the backup's own traffic through the master with a gateway group (tier 1 = the ISP gateway on WAN, tier 2 = the peer's SYNC IP) plus outbound NAT on the master that translates the backup's SYNC subnet to the public VIP. dpinger tracks the CARP role for you, because only the master can source probes from the VIP.

One clarification for your case: your /30 is static, so you do NOT need any DHCP lease-keeping — you just assign the public IP to the CARP VIP directly (or bind it as an IP-alias VIP to the CARP VIP, as you suggested). A plugin only enters the picture if that single public address is handed out by DHCP, where something has to keep the lease alive on the CARP virtual MAC as it floats. For a static /30, skip that part — everything else in the writeup applies unchanged.

I've written the whole single-IP design up — the gateway group, the backup-internet options, the CARP mechanics and the open risks: https://github.com/toreamun/opnsense-plugins/blob/main/net/os-carp-vip-dhcp/docs/single-ip-wan-carp.md (plugin + README: https://github.com/toreamun/opnsense-plugins/tree/main/net/os-carp-vip-dhcp)

Fair warning: the end-to-end single-IP topology is theoretical/untested — the lease-keeping core is proven, but the private-WAN + gateway-group part isn't — so I'd genuinely value a report back if you get it working on your /30.