Bug #11793

OpenVPN client starts on CARP Backup when bound to Virtual IP aliased to CARP address

Added by monotype tattoo about 1 month ago. Updated 20 days ago.

Pull Request Review
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


If an OpenVPN client is bound to a virtual IP which is an IP Alias for a CARP IP, the OpenVPN client (e.g. ovpnc1) gets started when the parent CARP interface's state is BACKUP.

With a site-to-site UDP OpenVPN tunnel where the client sits on a redundant pair of pfSense hosts, this causes the stand-by to steal the OpenVPN connection from the active firewall and as a result, traffic received by the active firewall destined for the OpenVPN tunnel is dropped. This continues until a ping activity timeout occurs and restarts the OpenVPN service on the active firewall. The OpenVPN tunnel will then remain up for some time (usually minutes) until once again, a ping activity timeout occurs and restarts the OpenVPN service on the standby firewall.

With a TCP OpenVPN tunnel, the client on the standby firewall will receive a TCP timeout. However, we think we see some knock-on with TCP tunnel connection quality (dropped packets) whilst the standby firewall's OpenVPN process attempts to make the connection.

I think this statement in needs changing to also check whether the bound interface is virtual IP aliased to a CARP IP before proceeding to call restart_openvpn:

if (($a_groups[$settings['interface']][0]['vip'] <> "") && (!in_array(get_carp_interface_status($a_groups[$settings['interface']][0]['vip']), array("MASTER", ""))))


I am raising this as high priority because it has been a significant issue for us in a production environment where we would ideally use a seperate IP for VPN versus customer traffic (other wise face the peril of colo providers DDOS protection system) and we would ideally keep the number of CARP addresses to a minimum so that we don't have IP addresses failing over independently.


#2 Updated by Jim Pingle 20 days ago

  • Status changed from New to Pull Request Review
  • Priority changed from High to Normal
  • Target version set to 2.6.0

Also available in: Atom PDF