Project

General

Profile

Actions
Copy link

Feature #15243

open

CARP causes tinc termination

Added by Michael Lipp 3 months ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Tinc
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:

Description

Obviously, using CARP (rc.carpbackup from the logs) kills tinc on the router that CARP considers backup. However, this does not conform with my tinc usage. I need the tinc daemons on both routers to run. There must be a possibility to exclude tinc daemon management from CARP.

Actions
Copy link
 #1

Updated by Jim Pingle 3 months ago

  • Tracker changed from Bug to Feature
  • Project changed from pfSense to pfSense Packages
  • Category changed from VPN (Multiple Types) to Tinc
  • Release Notes deleted (Default)
  • Affected Architecture deleted (All)
Actions
Copy link
 #2

Updated by dylan mendez about 2 months ago

By "kills tinc" it means tinc stops functioning completely or just on the CARP interface?

If you have the Local IP configured in tinc to be the CARP IP, due to the fact that the CARP IP is not owned by the secondary firewall, it will not be able to bind it (Because the IP address doesn't really exist in the secondary until the primary goes down). This is expected behaviour.

Actions
Copy link
 #3

Updated by Michael Lipp about 2 months ago

I have only one tincd process (which is in no way related to any VIP managed by CARP) and it is "stopped" (i.e. eventually killed).

The plugin (/usr/local/pkg/tinc.inc) does not check for any relationship with a VIP. It simply "says": if I have become the backup, I stop tinc:

                if ($pluginparams['event'] == 'rc.carpbackup') {
                        // stop
                        log_error("[tinc] got CARP:BACKUP -> stopping");
                        if (!is_service_running('tinc')) {
                                log_error("[tinc] already stopped");
                        } else {
                                // Commented out to keep tinc running, see https://redmine.pfsense.org/issues/15243
                                // stop_service("tinc");
                        }
                }

This is contrary to the "normal" (IMHO) usage of tinc. As tinc spawns a mesh network, fail-over is completely managed by tinc. If a daemon becomes unreachable using a specific connection, the traffic is routed through other connections. Therefore, if tincd keeps running, I can still reach my routers through the tinc overlay network (using their addresses in the tinc VPN) as long as there is one remaining network connection (which might even go through other nodes behind the routers).

As my routers have one dedicates LAN connection to talk with each other (and more ways to connect using machines behind the routers) there is absolutely no reason to bring tincd down, simply because the WAN interfaces change their roles. (Actually, they even don't have to change roles, because /usr/local/pkg/tinc.inc is invoked regularly with even rc.carpbackup on the backup if you use CARP.)

Actions
Copy link

Also available in: Atom PDF