Project

General

Profile

Actions

Bug #11793

closed

OpenVPN client starts when CARP VIP is in BACKUP status when bound to Virtual IP aliased to CARP VIP

Added by monotype tattoo 7 months ago. Updated 4 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
OpenVPN
Target version:
Start date:
04/09/2021
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
21.05
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.

Actions #2

Updated by Jim Pingle 6 months ago

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

Updated by Jim Pingle 6 months ago

  • Plus Target Version set to 21.05
Actions #4

Updated by Steve Beaver 6 months ago

  • Status changed from Pull Request Review to Feedback
Actions #5

Updated by Viktor Gurov 6 months ago

  • % Done changed from 0 to 100
Actions #6

Updated by Jim Pingle 6 months ago

  • Subject changed from OpenVPN client starts on CARP Backup when bound to Virtual IP aliased to CARP address to OpenVPN client starts in CARP Backup status when bound to Virtual IP aliased to CARP VIP

Updating subject for release notes.

Actions #7

Updated by Jim Pingle 5 months ago

  • Target version changed from 2.6.0 to 2.5.2
Actions #8

Updated by Jim Pingle 5 months ago

  • Category changed from CARP to OpenVPN
Actions #9

Updated by Jim Pingle 5 months ago

  • Subject changed from OpenVPN client starts in CARP Backup status when bound to Virtual IP aliased to CARP VIP to OpenVPN client starts when CARP VIP is in BACKUP status when bound to Virtual IP aliased to CARP VIP

Fixing up subject

Actions #10

Updated by Jim Pingle 5 months ago

  • Status changed from Feedback to Closed
Actions #11

Updated by Renato Botelho 4 months ago

  • Assignee set to Viktor Gurov
Actions

Also available in: Atom PDF