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.)