Messages

[Single-IP is now field-validated.]

A few things have moved since the first post:

• Single-IP is now field-validated. The whole single-IP topology has run on a live one-IP DHCP WAN, including a real CARP failover (the promoted node routed straight out the VIP). Still a single deployment, so more field reports across different ISP/CPE combinations are very welcome.
• Backup egress is now built in. On a single-IP setup the backup node reaches the internet through the master automatically (a leak-safe route set, withdrawn again on promotion), instead of a manual or gateway-group workaround.
• Default-route ownership by CARP role. The keeper can own the WAN default route as a function of CARP role and lease (off / observe / enforce), so a failover moves the default with the role and a backup never black-holes a route it cannot use.

Docs and installer: https://github.com/toreamun/opnsense-plugins

[If you run (or want to run) an OPNsense HA pair with CARP but your WAN is DHCP-assigned rather than static, you've probably hit this wall: the docs assume 3 static WAN IPs, and stock CARP can't work on DHCP or single IP. This plugin closes that gap.]

If you run (or want to run) an OPNsense HA pair with CARP but your WAN is DHCP-assigned rather than static, you've probably hit this wall: the docs assume 3 static WAN IPs, and stock CARP can't work on DHCP or single IP. This plugin closes that gap.

Why stock CARP can't do it: a CARP virtual IP is static, and a DHCP WAN only routes an address while a live DHCP lease is bound to its MAC - so the VIP never gets a lease and never receives traffic. dhclient can't help either: it can't decouple the DHCP chaddr from the interface's hardware MAC.

What it does: a small daemon keeps a DHCP lease alive for the CARP VIP's virtual MAC. The ISP then routes the VIP to that MAC, native CARP answers ARP and fails over as usual - so the shared IP works and fails over on a dynamic WAN. Runs on both nodes redundantly, follows a changing address, and keeps the upstream ARP fresh (some gateways silently blackhole otherwise).

Tested on two independent real ISP lines (one CGNAT, one a plain public-DHCP WAN). On a two-node bench the whole path is verified end-to-end: the VIP holds its lease on the virtual MAC, CARP fails over cleanly (master link down -> backup takes over, VIP held), the ARP nudge is answered by the real ISP gateway, and follow works (the VIP tracks a changed address without ever dropping the lease).

When it applies: an HA pair + a DHCP (not static/PPPoE) WAN. Works whether the line hands out several concurrent leases (one per node's WAN + one for the VIP - the straightforward case) or only a single address.

Only a single IP? Supported too - a single floating VIP holds the one lease while each node uses a private WAN IP for CARP, and the backup reaches the internet through the master. The whole single-IP topology has now been field-run on a live one-IP DHCP WAN, including a real CARP failover. Still a single deployment, so field reports from other single-IP WANs (different ISP/CPE) are very welcome.

Also worth knowing for HA: for outbound traffic to survive a failover, point Outbound NAT at the CARP VIP (not a node's own WAN address). If the address is dynamic, the plugin can keep a firewall alias in sync so NAT/rules follow it automatically.

Personal third-party plugin for now. If there's interest I'd like to propose it for the official OPNsense community plugins - so say so if it'd be useful, and a star on the repo helps make that case.

Repo + one-line installer: https://github.com/toreamun/opnsense-plugins

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.

If the reason there's no WAN CARP VIP is that the WAN is DHCP (a static VIP gets no traffic), there's a way now: os-carp-vip-dhcp keeps a DHCP lease alive for the CARP VIP's virtual MAC so it's actually routed and can fail over. The straightforward setup wants a few concurrent leases (one per node + one for the VIP) — any DHCP line handing out several addresses (tested on both a public-DHCP and a CGNAT line). I've also sketched a single-IP variant (private per-node WANs for CARP advertisements + one floating VIP holding the single lease) — but it's theoretical and untested, so I'd be genuinely grateful if anyone on a one-IP line tried it and reported back. Personal plugin for now; if there's interest I'd like to get it into the official community plugins. Repo + the single-IP writeup: https://github.com/toreamun/opnsense-plugins

The docs basically say CARP needs static/multiple WAN IPs, and that's the wall: CARP gives you a static shared VIP, but a DHCP WAN only routes an address while a live lease is bound to its MAC — so the static VIP never gets traffic. I wanted HA on a DHCP WAN and wrote a plugin for it: os-carp-vip-dhcp keeps a DHCP lease alive for the CARP VIP's virtual MAC, so the ISP routes it and normal CARP failover works on a dynamic WAN (it also follows a changing address). Any DHCP line that leases a few addresses works — I've run it both on a plain public-DHCP WAN and behind CGNAT. Personal third-party plugin for now; if there's interest I'd like to try getting it into the official community plugins, so let me know if it'd help you. Repo: https://github.com/toreamun/opnsense-plugins (net/os-carp-vip-dhcp)

This thread is about exactly the problem I had - running a CARP WAN when the ISP hands you the address over DHCP (mine is a CGNAT fiber link). I ended up solving it as a proper OPNsense plugin rather than a script, in case it's useful to anyone here.

Approach: the scripts in this thread up/down the WAN interface (and juggle MAC spoofing / write_config) on each CARP transition. This plugin does something different - it keeps a dedicated DHCP lease alive for the CARP VIP's virtual MAC (00:00:5e:00:01:<vhid>). Whichever node is MASTER answers on that MAC and holds the lease, so the ISP hands the WAN address to the active node. No interface up/down, no MAC-spoof juggling, no write_config on every event.

Prerequisite: your ISP's DHCP server has to be willing to hand out a lease to the CARP VIP's virtual MAC - i.e. it can serve more than one active address on your WAN (your box already has its own, the VIP needs an additional one). If your ISP binds the line to a single MAC / a single address, this approach won't work. In my case the ISP gives the VIP MAC its own DHCP reservation. An untested  design write-up exist for situations where only one active lease can exist: https://github.com/toreamun/opnsense-plugins/blob/main/net/os-carp-vip-dhcp/docs/single-ip-wan-carp.md

What it gives you over a raw script:
- Native plugin with a GUI (Interfaces -> Virtual IPs DHCP) - no editing PHP/shell
- Signed releases + a one-line verified installer

Install (OPNsense 26.1, as root):

Code Select Expand

fetch -o - https://raw.githubusercontent.com/toreamun/opnsense-plugins/main/install.sh | sh
The installer verifies the release signature against the committed public key before installing.

Repo: https://github.com/toreamun/opnsense-plugins

Full disclosure: my own project, currently v1.0, and tested mainly in my own setup (CGNAT fiber, active/passive OPNsense pair) - not yet widely deployed. Feedback and issues very welcome, happy to answer questions here.

If you give it a try, I'd love to hear how it goes — drop a comment or open an issue on GitHub. If there's enough interest I'm considering submitting it to the official OPNsense plugins repo.