pfSense

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 openvpn.inc 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.