pfSense

Description¶

Currently, configuring a robust, dual-stack (IPv4 + IPv6) OpenVPN Site-to-Site (P2P) tunnel on a pfSense High-Availability (HA) cluster with CARP is unnecessarily complex and counterintuitive for system administrators.

Because the OpenVPN daemon cannot natively bind to two specific, distinct Virtual IPs (an IPv4 CARP VIP and an IPv6 CARP VIP) simultaneously using standard UDP, administrators are forced into messy workarounds.

The Problem with Current Solutions¶

1. Splitting into two separate UDP instances (One IPv4, One IPv6): This requires using two different ports (e.g., 1234 and 1235) and setting up complex Policy-Based Routing with Gateway Groups/Failover on both sides to handle the dual routing tables (ovpns1 and ovpns2).
2. Using TCP / Localhost with Port Forwarding: This allows using a single port, but it completely breaks the native pfSense CARP service automation. Because OpenVPN binds to Localhost (127.0.0.1 / ::1), pfSense does not stop the service on the BACKUP node. The BACKUP node keeps injecting active VPN routes into the kernel, routing table conflicts arise, and custom shell scripts (devd) are required to forcefully kill the daemon during a CARP transition.

The Core Misunderstanding in Current Design¶

The pfSense UI currently blocks the user from selecting a CARP VIP if a "Multihome" protocol is chosen. The underlying logic assumes that a service set to any (Multihome) is a global system daemon that should run on both nodes simultaneously.

However, in reality, there is almost no real-world use case where an administrator wants an XMLRPC-synchronized OpenVPN server to actively run and accept traffic on both the MASTER and BACKUP nodes at the same time. Having the service active on the BACKUP node only leads to routing conflicts, split-brain scenarios, and asymmetric traffic behaviors.

Proposed Feature / Solution¶

We propose a UI and backend enhancement: Allow the selection of an "Interface" (specifically a CARP VIP) even when a Multihome/Dual-Stack protocol is selected.

In this configuration, the selected CARP VIP would not overwrite the OpenVPN bind directive to a specific IP, but would instead act purely as a "Service Status Trigger Interface" (Tracking Interface).

• Behavior on MASTER: pfSense detects the selected CARP VIP is MASTER -> starts the OpenVPN daemon.
• Behavior on BACKUP: pfSense detects the selected CARP VIP is BACKUP -> natively stops/kills the OpenVPN daemon, removing its routes cleanly from the backup node's kernel.

Comparison of Architectural Approaches¶

Approach	Pros	Cons
Current UDP Split (2 Instances)	Native CARP sync works fine. \ Good UDP performance.	Requires 2 separate open ports. \ Highly complex routing/gateway groups.
Current Localhost TCP (1 Instance)	Single port for IPv4/IPv6. \ Unified routing table.	Native CARP failover is broken. \ Requires unsafe custom devd cron/shell scripts.
Proposed Solution (Multihome + Trigger)	Single port for Dual-Stack. \ Unified routing table. \ 100% native pfSense HA automation.	Requires code adjustments in vpn_openvpn_server.php and CARP event handlers.

Conclusion¶

Implementing a "Trigger/Tracking Interface" option for Multihome OpenVPN servers would drastically lower the complexity barrier for modern Dual-Stack HA deployments. It aligns with how human administrators actually manage HA clusters (ensuring services only run where the Virtual IP is active) rather than forcing them into brittle script-based workarounds.