tuto-pfsense-cluster-psync-carp - My Personal Knowledge Base

> [!danger] Rappel ! Ceci est un brouillon en cours de correction, il peut contenir de nombreuses erreurs de frappes ou des incohérences. # Cluster Haute disponibilité pfSense Dans les infrastructures réseau critiques, la **continuité de service** est essentielle. Pour éviter toute interruption liée à la panne d’un équipement, il est courant de déployer un **cluster de passerelles** : plusieurs nœuds identiques travaillent ensemble pour qu’un autre prenne automatiquement le relais en cas de défaillance. Cette approche est couramment mise en œuvre via des protocoles comme **HSRP** (Cisco) ou **VRRP** (standard IETF), qui permettent la redondance des passerelles. La haute disponibilité du logiciel pfSense est obtenue grâce à une combinaison d'outils : - CARP pour la redondance des adresses IP - XMLRPC pour la synchronisation de configuration - pfsync pour la synchronisation des tables d'état Avec cette configuration en place, les nœuds agissent comme un cluster “actif/passif” avec le nœud principal fonctionnant comme nœud actif et le nœud secondaire dans une sauvegarde “rôle de style veille à chaud”, prenant le relais si nécessaire si le nœud principal tombe en panne. Cette solution permet la configuration d'un cluster pfSense HA (Hight Availability ou Haute Disponibilitée en français). ## CARP (Protocole de redondance d'adresse commune) Common Address Redundancy Protocol (CARP) a été créé par les développeurs OpenBSD en tant que solution de redondance gratuite et ouverte pour partager des adresses IP entre un groupe de périphériques réseau. C'est une alternative à la solution propriétaire HSRP/VRRP de Cisco. Ce protocole permet à un groupe d'hôte de **partager une IP virtuelle (VIP)** et fonctionne en mode actif/passif. Le nœud “actif” détient la VIP CARP et répond aux requêtes. Si le nœud actif échoue, le nœud de secours **prend en charge l'adresse VIP**, ce qui permet la continuité de service. Pour que le basculement fonctionne, la VIP CARP doit être utilisée comme passerelle par défaut (inbound et outbound). > [!info] À savoir ! Le signal de hearthbeat transite sur toutes les interfaces qui disposent d'une VIP CARP. ## pfsync Pfsync garantit que **états des sessions actives en TCP/UDP sur pare-feu actif sont synchronisés sur le firewall secondaire**. De cette façon, en cas de basculement, les sessions actives (RDP, HTTP, SSH, etc.) ne seront aps interrompues. Par exemple, un fichier en cours de téléchargement, ou une session SSH à distance. Warning pfsync does not support any method of authentication. If this option is set to anything other than an isolated segment it is possible for a user with access to the network on that interface to manipulate the state table. For example, they could insert states into the state table. ## XMLRPC La synchronisation XMLRPC sous pfSnese est un mécanisme qui permet au nœud principal de **synchroniser automatiquement et en temps réel les modifications de configuration** (règles de pare-feu, NAT, DHCP, etc.) Le cluster pfSense fonctionne avec un **Master** (actif) et des **Backup** (en veille), utilisant un réseau dédié pour les annonces CARP, pfsync et XMLRPC, assurant isolation et performance. Warning XMLRPC configuration synchronization must only be enabled on the primary node! It is not possible to synchronize settings from a secondary node back to the primary node. Warning The interfaces on both nodes **must** be assigned **identically**, for example: wan=WAN, lan=LAN, opt1=Sync, opt2=DMZ. Check the `config.xml` contents directly to ensure a match. If the interfaces do not match up exactly, firewall rules and other configuration items will appear to synchronize to the wrong interface on the secondary node. There are a few requirements for this to work properly: - The target firewall must be running the same version of pfSense software - The target firewall GUI must be running the same protocol (HTTPS or HTTP) - The target firewall GUI must be running on the same port (e.g. `443` or `80`) ## Étapes préalables et prérequis ### Organisation des flux trafic de synchronisation Il est essentiel de distinguer clairement les différents flux HA, car chacun opère à un niveau différent : - La synchronisation de configuration et des états s’effectue sur une interface dédiée (**SYNC**). - Le heartbeat CARP circule uniquement sur les interfaces possédant une VIP (**WAN** et **LAN**). - Le signal de bascule (failover) est diffusé sur toutes les interfaces configurées avec CARP. Il est important de faire la distinction entre les trois fonctions (adresse IP, redondance, synchronisation de configuration et synchronisation de table d'état), car ils s'exécutent à différents niveaux. - Synchronisation de configuration et de la table d'états sur une interface dédiée (souvent nommée "SYNC"). - Le heartbeat CARP s'effectue sur l'ensemble des interfaces disposants d'une VIP. - Le signal de failover est envoyé sur toutes les interfaces avec CARP activé. > [!danger] Attention ! L'interface **SYNC** doit être **dédiée** et **réservée aux communications HA**. Ne mélangez jamais ce trafic avec d'autres segments (LAN ou WAN). CARP repose sur de la multidiffusion. Vérifiez que votre switch : - Autorise l’envoi et la réception de trafic multicast sur les ports concernés. - Permet l’utilisation de plusieurs adresses MAC par port. - Accepte la migration d’une adresse MAC (la MAC virtuelle CARP) d’un port à l’autre. ### Cas particulier avec ESXi Par défaut, un vSwitch ESXi bloque le trafic utilisé par CARP. : - **Mode promiscuité** : Autoriser les vNIC connectées à recevoir tout le trafic du Port Group, y compris les paquets non destinés à leur MAC. - **MAC Address Changes** : Accepter les modifications de MAC, car le protocole CARP utilise une adresse MAC virtuelle partagée entre les nœuds. - **Forged Transmits** : Autoriser l’envoi de paquets dont la MAC source ne correspond pas à celle de la vNIC, condition nécessaire au fonctionnement de CARP. > [!info] À savoir ! Aucun réglage n’est requis sur l’interface SYNC, car elle n’embarque pas de VIP CARP. Voici la liste des paramètres de sécurité des Ports Groups WAN et LAN : ![[_asset-tuto-pfsense-cluster-psync-carp.png]] > [!danger] Attention ! N’appliquer ces réglages que sur des Port Groups dédiés à pfSense, car ils augmentent la surface d’attaque et peuvent permettre l’usurpation de MAC en production. # Configurer la haute disponibilité Cette étape décrit la configuration d'un cluster de haute disponibilité (HA) logiciel pfSense avec deux nœuds (primaire et secondaire) qui contiennent chacun trois interfaces : WAN, LAN et Sync. Dans cette configuration, nous ne couvrirons que les configurations IPv4 mais en environnement de production il pourrait être nécessiare d'activer le protocole IPv6 (notammenet sur la partie WAN). ### Définition du plan IP du cluster Un cluster HA pfSense doit disposer à minima de trois adresses IP sur les segments disposant d'une VIP CARP. Il faut prévoir également deux adresses IPv4 dédiées sur le segment réservé à la synchronisation. Dans notre configuration, nous utiliserons le plan d'adressage IPv4 suivant : | Interface | PFS1 | PFS2 | VIP CARP | | --------- | ------------------ | ------------------ | ------------------ | | **WAN** | 172.30.0.251/23 | 172.30.0.252/23 | 172.30.0.254/23 | | **LAN** | 192.168.200.251/24 | 192.168.200.252/24 | 192.168.200.254/24 | | **SYNC** | 10.0.0.1/30 | 10.0.0.2/30 | N/A | > [!info] À savoir ! Les adresses IP sur l'interface Sync sont utilisées uniquement pour la communication entre les pare-feu. Comme il n'y a pas d'autres appareils sur le réseau Sync, nous utiliserons un masque en /30 et il n'est pas utile d'ajouter une VIP sur cette interface. ### Définition du schéma cible ## Installation des deux nœuds pfSense Nous nous appuierons sur un environnement virtuel vSphere ESXi 8 U2 pour déployer la version communautaire **pfSense CE 2.7.2**, car elle est basée sur FreeBSD 14 (seule version actuellement supportée par notre hyperviseur). > [!info] À savoir ! Le choix de la version 2.7.2 a été réalisée à l'aide de la [matrice de compatibilité vSphere](https://compatibilityguide.broadcom.com/search?program=software&persona=live&column=osVendors&order=asc) et de la [documentation pfSense CE software](https://docs.netgate.com/pfsense/en/latest/releases/versions.html#pfsense-ce-software). La procédure d'installation pfSense n'est détaillée dans cet article. Un tutoriel dédié a été rédigé et utilisé spécifiquement pour cette démonstration, consultez la procédure annexe d'[[tuto-pfsense-install|Installation de pfSense sous vSphere ESXi8]]. > [!danger] Attention ! Il faut attribuer les interfaces dans le même ordre et les configurer de façon identiques sinon des erreurs de synchronisation peuvent e produires. Après l'installation, connectez-vous à l'interface graphique et utilisez l'assistant de configuration pour configurer chaque nœud avec un nom d'hôte unique et des adresses IP statiques non conflictuelles. Voici les illustrations qui démontrent la configuration sur les machines PFS1 et PFS2 : ![[_asset-tuto-pfsense-cluster-psync-carp-16.png]] ![[_asset-tuto-pfsense-cluster-psync-carp-16-1.png]] # Installation des noeuds pfSense L’installation des firewall pfSense s'est second firewall pfSense se fera de la même manière que celle que nous avons vu plus tôt dans ce tutoriel [[tuto-pfsense-install]] sauf que nous lui allouerons 3 interfaces réseaux. ### Ajouter une interface réseau Arrêtez votre pfSense et ajoutez une interface réseau. UNe fois la modification effectuée, lancez le système et connectez vous à l'interface GUI de votre pfSense. ### Configurer l'interface de synchronisation Les interfaces de synchronisation ont été ajoutées et configurées selon le [[tuto-pfsense-cluster-psync-carp#Définition du plan IP du cluster|plan d'adressage IP]] définit précédemment. Il faut, à présent, ajouter les règles de pare-feu sur les deux nœuds pour permettre la synchronisation. Voici un tableau clair regroupant les règles à appliquer sur l’interface de synchronisation entre PFS1 et PFS2. | Service / Fonction | Protocole | Port(s) | Source | Destination | Action | Commentaire | | -------------------- | --------- | ------------- | ------------ | ------------ | ------ | ----------------------------------- | | Sync Config (XMLRPC) | TCP | 443 | SYNC Subnets | SYNC Address | Pass | Synchronisation de configuration HA | | pfsync | pfsync | N/A | SYNC Subnets | any | Pass | Synchronisation des états | | Kea DHCP HA | TCP | 8765–8766 | SYNC Subnets | SYNC Address | Pass | Haute disponibilité Kea | | ICMP Echo Request | ICMP | Echo (type 8) | SYNC Subnets | SYNC Subnet | Pass | Diagnostic / ping | Les règles sont à ajouter dans "*Firewall > Rules > SYNC*". UNe fois les configurations créées et appliquées vous obtiendrez la configuration suivante : ![[_asset-tuto-pfsense-cluster-psync-carp-16-2.png]] > [!warning] Nous avons désactivé la règle Kea DHCP, car nous n'allons pas configurer de cluster DHCP à ce stade. # Configurer la HA Les configurations doivent être réalisées, sur les deux noeuds. Débutez par la configuration de PFS1 et répétez l'oprération sur PFS2. La haute disponibilité vi pfsync et XMLRPC sync s'effectuent dans le menu **System > High Availability**. ## Configurer la synchronisation d'état avec pfsync La synchronisation d'état à l'aide de pfsync doit être configurée à la fois sur les deux nœuds PFS1 et PFS2. Nous commençons par le nœud principal (PFS1), rendez-vous dans **System > High Availability**, section **pfsync** : - Cochez la case **Synchronize states** - Dans la liste délourante **Synchronize interface**, choisissez la carte nommée "*SYNC*". - Définir la valeur **Filtrer host ID**, par exemple `1` sur le nœud principal et `2` sur le nœud secondaire. - Renseignez **pfsync Synchronize Peer IP** avec l'adresse SYNC de l'éauree noeud. Par exemple sur PFS1, vous saisirez l'ip sync de PFS2 (10.0.0.2). - Pour finir, cliquez sur Save et reproduire la configuration sur le second noeud. Ci-dessous un exemple de configuration du PFS1 ![[_asset-tuto-pfsense-cluster-psync-carp-16-3.png]] If the interfaces are not both physically identical and assigned in the same order on both nodes then the states will not properly sync, for example if WAN is `ix0` on one node and `igb0`on the other. While having identical hardware is always the best practice, mismatched hardware can still function with Interface Bound States by using LAGG interfaces to abstract the assignments. LAGGs can work around this since the states would be bound to the `laggX` interface on each node rather than the underlying physical interface. For example, `lagg0` on primary contains `ix0`, `lagg0` on secondary contains `igb0`, but the states use `lagg0` on both nodes, so sync will function. ## Configurer la synchronisation des configuration avec XMLRPC Sync As a general rule, items specific to hardware or a particular installation, such as Interfaces or values under **System > General** or **System > Advanced** do not synchronize. The list of supported areas can vary depending on the version of pfSense software in use. For a list of areas that will synchronize, see the checkbox items on **System > High Availability** in the XMLRPC section. Most packages will not synchronize, but some contain their own synchronization settings. Consult package documentation for more details. > [!danger] Attention ! La synchronisation de configuration **ne doit être configuré que sur le nœud primaire** (PFS1). N'activez jamais les options de cette section sur le nœud secondaire (PFS2). Sur le nœud principal **seulement** (PFS1), rendez-vous dans **System > High Availability**, section **XMLRPC sync** : - Synchronize Config to IP : saisir l'IPv4 de l'interface de synchronisation de PFS2 `10.0.0.2` - Remote System Username : Saisir le nom d'utilisateur `admin` - Remote System Password : Saisir le mot de passe webConfigurator du compte admin et et répétez la saisie du mot de passe pour confirmer. - Il faut ensuite cocher toutes les cases afin de synchroniser l'ensemble des options. - Enfin, cliquez sur **Save**. > [!info] À savoir ! Il est recommandé d'utiliser un compte utilisateur dédié, à créer sur les deux nœuds, avec le “Privilège Système - Synchronisation du nœud HA”. Pour confirmer que la synchronisation a fonctionné, vous pouvez par exemple ajouter ou modifier une règle de parfeu sur PFS1 et constater qu'elle est automatiquement ajoutées ou modifiées dans les règles de PFS2. > [!done] Félicitations ! Les deux nœuds sont désormais liés pour la synchronisation de la configuration ! PFS1 se synchronisera avec FS2, chaque fois qu'une modification est apportée au nœud principal nœud. ## Configuration des adresses IP virtuelles CARP La synchronisation de configuration est en place, les adresses VIP CARP seront ajoutée à partir du noeud principale PFS1 et elles se rajouterontautomatiquement sur PFS2 (noeud secondaire). Chaque VIP a besoin d'un VHID unique par domaine de diffusion (couche de niveau 2 du modèle OSI). Ci-dessous la liste des VHID que nous avant alloué au VIP CARP du [[tuto-pfsense-cluster-psync-carp#Définition du plan IP du cluster|plan d'adressage IP]] définit précédemment. | Interface | VIP CARP | VHID | | --------- | ------------------ | ----- | | **WAN** | 172.30.0.254/23 | `172` | | **LAN** | 192.168.200.254/24 | `192` | | **SYNC** | N/A | N/A | > [!info] À savoir ! Seules les interface qui supporte du traffic réseau lié aux utilisateurs ont besoin d'une VIP CARP. Pour ajouter les VIP, sur PFS1 uniquement : - Naviguez dans le menu **Firewall > Virtual IPs** - Cliquez sur le bouton `[+]` en haut de la liste pour créer une nouvelle VIP - Saisir la VIP selon l'interface : - **Type** : CARP - **Interface** : saisir l'interface liée à la VIP. Par exemple WAN - **Address** : Saisir l'adresse le tableau des VIP selon le [[tuto-pfsense-cluster-psync-carp#Définition du plan IP du cluster|plan d'adressage IP]] et le CIDR. - **VHID Group** : Saisir l'ID selon le tableau de correspondance ci-dessus. - **Virtual IP Password** : Utilisez une valeur aléaoitre, cette valeur sera automatiquement synchronisée vers PFS2. - **Advertising Frequency** : Fréquence à laquelle le nœud envoie des heartbeat CARP sur son interface SYNC. - **Base** : Secondes entières entre les battements de cœur, généralement *1*. - **Skew** : Fractions d'une seconde (incréments de 1/256e). Généralement 0 ou 1 sur le noeud principale - **Description** : Saisissez un descriptif pour identifier plus facielement la VIP. Par exemple `VIP WAN`. - Cliquez sur **Apply Changes** pour terminer la procédure > [!info] À savoir ! Un nœud principal est généralement défini sur 0 ou 1, les nœuds secondaires seront 100 ou supérieur. Ce réglage est géré automatiquement par XMLRPC synchronisation. Voici un exemple de configuration poru la VIP WAN : ![[_asset-tuto-pfsense-cluster-psync-carp-16-4.png]] > [!warning] Rappel ! Le masque de sous réseau de la VIP doit correspondre à celui de l'interface physique. Après avoir ajouté des VIP, vérifiez **Firewall > Virtual IPs** sur le second noeud PFS2 que les VIP se sont synchronisés comme prévu. Si le processus réussi la liste des adresses IP virtuelles s'affichera : ![[_asset-tuto-pfsense-cluster-psync-carp-16-5.png]] ## Configurer le NAT sortant pour CARP Par défaut, pfSense génère automatiquement les règles de NAT Outbound. Dans le cadre d’un cluster HA, il est recommandé de passer en mode hybride afin de pouvoir définir manuellement les règles de NAT des VIP. Ce mode permet de conserver la création de règles automatiques lors de l’ajout de nouvelles interfaces ou de nouveaux réseaux. L'étape suivante consiste à configurer le NAT sortant afin que le pare-feu masque l'IPv4 source des clients LAN avec la VIP CARP WAN à la sortie du trafic vers Internet : - Naviguez vers **Firewall > NAT > Outbound** - Cliquez sur le mode **Hybrid Outbound NAT rule generation**. - Cliquez sur **Save**. ![[_asset-tuto-pfsense-cluster-psync-carp-16-6.png]] Pour créer une nouvelle règle de NAT du réseau LAN (`192.168.200.0/24`) via VIP WAN (`172.30.0.254/23`) : - Cliquez sur le bouton `[Add]` - Interface : WAN - Address Family : IPv4 - Source : LAN Subnets - Translation, Address : Choisr la VIP WAN dans la lise déroulante `172.30.0.254/23`. - Description : Saisir un descriptif de cette nouvelle règle de NAT, par exemple : `LAN to WAN via VIP` - Laissez autres opotions par défaut et cliquez sur **Save**. Si vous envisagez d'utiliser des VPN IPSEC depuis le LAN, il faudra ajouter une règle spécifique avec du PNAT Static sur le port 500 (ISAKMP). > [!warning] Rappel ! Si une nouvelle interface est ajoutée ultérieurement, vous devrez ajouter une règle de NAT sortante en conséquence. A ce stade, votre cluster HA pfSense est opérationnel et synchronisé ! Il es ttemps de lancer la procédure de test pour confirmer. testing procedure in [Verifying Failover Functionality](https://docs.netgate.com/pfsense/en/latest/highavailability/test.html) to confirm it is operating properly. # Tests et vérification de basculment La mise en place du basculement augemente la résiliance du système. Cependant une superivsion proactive et des tests réguliers sont nécessaire poru garantir : le statuit CARP, la synchronisation de l'état des connexions, la réplication des configurations et un tests de basculement (simulation de panne). ## Vérifier le statut de CARP Pour vérifier les status du protocole CARP, il faut se connecter sur les deux noeuds et parcrour le menu **Status > CARP (failover)**. Si tout fonctionne noramelemtn les VIP seront dans un status MASTER sur PFS12 et BACKUP sur PFS2. Le status des interfaces peut varier : ![[_asset-tuto-pfsense-cluster-psync-carp-16-7.png]] ![[_asset-tuto-pfsense-cluster-psync-carp-16-8.png]] ## Vérifier la synchronisation des états Pour vérifier le statut de la synchronisation de l'état des connexions actives entre les deux noeuds, utilisez le menu **Status > CARP** puis regarder la section **State Synchronization Status**. - Si les listes sont identiques sur chaque noeuds alors la synchronisation des états est fonctionnement. - Si la liste ne contient pas d'entrée pour l'ID du second nœud, alors les états ne sont pas synchronisés. Ci dessous un exemple qui démontre que nos Host IDS sont visible, sur PFS1 sur PFS2 : ![[_asset-tuto-pfsense-cluster-psync-carp-16-9.png]] ![[_asset-tuto-pfsense-cluster-psync-carp-16-10.png]] ## Vérifier la réplication de configuration Il n'existe pas de façon native de vérifier la bonne synchronisation des configurations pfSense. Pour constater cette synchronisation : - Générez une modification mineure sur une règles de parfeu PFS1. Par exemple modifier un commentaire sur une règle de NAT. - Constatez que la modification est appliquée sur le noeud 2 - Dans **Status → System Logs → System → General**, vérifier que les évvènements XMLRPC sync se dérouelnt sans erreurs ![[_asset-tuto-pfsense-cluster-psync-carp-16-11.png]] # Simulation d'un incident et test de résilience Il est temps de tester le bon fonctionnement du cluster et sa tolérence aux pannes du noeud principal PFS1. Pour réaliser ce teste nous allons lancer un téléchargement d'un fichier volumineux depuis le poste LAN. Nous simulerons une interruption brutale d'alimentation sur PFS1 (maitre). La connexion du client et son téléchargements devraient se poursuivre sans interruption. > [!danger] Attention ! Avant de poursuivre, il est recommendé de faire un snapshot de votre VM et une sauveagrde de la configuration pfSense via **Diagnostics → Backup & Restore → Download configuration**. ### Configuration IP des terminaux Les clients (qu'ils soient DHCP ou statiques) doivent utiliser le **CARP VIP** comme **passerelle par défaut**. De cette façon, si le master tombe en panne, la bascule sur le nœud esclave sera transparente. Dans le cadre de cette démonstration, la configuration IPv4 des terminaux sera réalisée via une configuration statique. > [!info] À savoir ! L'utilisation de la VIP CAR évite les conflits de table ARP, la mise à jour du DHCP ou la reconfiugraiont manuelle des PC clients. Par exemple le poste d'administration PC-WIN11 dispose de la configuration suivante : ![[_asset-tuto-pfsense-cluster-psync-carp-16-12.png]] ![[_asset-tuto-pfsense-cluster-psync-carp-16-13.png]] ![[_asset-tuto-pfsense-cluster-psync-carp-16-14.png]] Vérifier **Statut > CARP (échec)** encore une fois sur le nœud secondaire, et il va maintenant signaler qu'il est **MAÎTRE** pour le LAN et le WAN VIP CARP. Remettez maintenant le nœud principal en ligne. Il retrouvera son rôle de **MAÎTRE**, et le nœud secondaire se rétrogradera à un **SAUVEGARDE** déclarer à nouveau. À tout moment À ce stade de ce processus, la connectivité Internet fonctionnera toujours correctement. Testez la paire HA dans autant de scénarios de défaillance que possible. Tests supplémentaires inclure: - Débranchez le câble WAN ou LAN - Tirez la prise d'alimentation du primaire - Désactivez CARP sur le primaire en utilisant à la fois la fonction de désactivation temporaire et mode de maintenance - Testez chaque système individuellement (éteignez le secondaire, puis rallumez-le et fermer la primaire) - Téléchargez un fichier ou essayez de diffuser de l'audio/vidéo pendant le basculement - Exécutez une requête d'écho ICMP continue (ping) vers un hôte Internet pendant la basculement Dans la vidéo ci-dessous on peut constater que malgré la défaillance du noeud princiapl PFS1 (rédémarrage brutal du système) ni les pings vers la VIP 192?168?2900.2654 ni le téléchargement de l'image ISO n'ont été interrompu. Cela démontre le bonfoncitonnement du cluster, et du protocoe;CARP. ![](https://youtu.be/ZnNf_QrHBf8) ## Conclusion Ouverture vers les autres spof : lire [Layer 2 Redundancy](https://docs.netgate.com/pfsense/en/latest/highavailability/layer-2-redundancy.html "Layer 2 Redundancy") pfSense HA transforme un seul pare-feu en un **cluster de pare-feu tolérant aux pannes**, vous permettant de : - Prévenir les temps d'arrêt - Maintenir les sessions actives pendant le basculement - Gérez votre configuration de manière centralisée - Éliminer l'intervention manuelle lors de la maintenance ou des accidents Le protocole open source **CARP** associé aux outils pfSense (pfsync et XML-RPC) permettent d'optimiser la résilience de façon simple et à moindre coût. ### Reférecnes - **Wikipedia** : [Common Address Redundancy Protocol](https://fr.wikipedia.org/wiki/Common_Address_Redundancy_Protocol) - **Cisco** : [HSRP - Informations générales et fonctionnement](https://www.cisco.com/c/fr_ca/support/docs/ip/hot-standby-router-protocol-hsrp/9234-hsrpguidetoc.html#toc-hId-336139297) - **Netgate** : [High Availability](https://docs.netgate.com/pfsense/en/latest/highavailability/index.html) Never access the firewall GUI, SSH, or other management mechanism using a CARP VIP directly. For management purposes, only use the actual IP address on the interface of each separate node and not the VIP. Otherwise, the client cannot determine beforehand which node it is accessing.