Project

General

Profile

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.

Status:
Pull Request Review
Priority:
Normal
Assignee:
-
Category:
CARP
Target version:
Start date:
04/09/2021
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
2.5.0
Affected Architecture:
All

Description

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", ""))))

[[https://github.com/pfsense/pfsense/blob/a7086b04cae21ca742fdeefd1019ee1401b6dded/src/etc/inc/openvpn.inc#L1500]]

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.

History

#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