Fail-Over PfSense via CARP et pfsync
Sommaire
I. Présentation
La tolérance de panne (aussi appelée Fail-Over) est un processus visant à assurer une disponibilité constante et continue d'éléments réseaux. Dans le cas de PfSense, le Fail-Over va nous permettre de faire travailler plusieurs Pfsense en les regroupant derrière une IP virtuelle unique. Derrière cette adresse IP unique se positionneront deux ou plusieurs Pfsense, le principe est alors que si l'un des Pfsenses tombe, un autre est présent pour prendre le trafic à sa place et ce de manière invisible pour l'utilisateur car la même IP virtuelle sera toujours utilisée.
Le fail-over peut ici être utilisé pour les interfaces coté WAN comme coté LAN. On retrouvera le même principe de fonctionnement que les protocoles HSRP (Cisco) ou GLBP et VRRP pour les autres vendeurs réseaux.
II. Protocole CARP
Le protocole CARP (Common address redundancy protocol) est le protocole utilisé par Pfsense pour la mise en place d'un Fail-over, notons qu'il peut être utilisé par de nombreux systèmes OpenBSD, FreeBSD et également Debian/CentOS via UCARP. CARP est un protocole travaillant sur les couches 2 et 3 du modèle OSI. Dans son fonctionnement, on met dans un groupe plusieurs hôtes (groupe de redondance) qui partageront alors une même adresse IP et auront une adresse MAC dite "virtuelle". Derrière cette adresse IP qui sera virtuelle se cacheront deux ou plusieurs hôtes parmi un maître qui prendra et traitera l'intégralité des requêtes en destination de l'IP virtuelle. Les hôtes du réseaux communiqueront entre eux afin de vérifier que le maître est toujours actif, s'il vient à tomber, l'hôte désigné comme esclave prendra le relais afin d’accueillir et de traiter le trafic en destination de l'adresse IP Virtuelle.
Ce genre de fonctionnement permet, si une passerelle tombe par exemple, de garder la même configuration en utilisant une passerelle physiquement différente car les deux ou plusieurs hôtes se "cacheront" derrière une IP unique. CARP est une alternative sécurisée aux protocoles HSRP ou VRRP car il implémente le SHA1-HMAC lors de ses échanges (appelé advertisment). Ceci bloquant, s'ils sont interceptés par un pirate, leur lecture et leur compréhension qui pourrait révéler des informations importantes sur le réseau.
Il est à noter que CARP supporte l'IPv4 et l'IPv6 et qu'un même hôte peut faire parti de plusieurs groupes de redondance à la fois.
III. Pfsync
Nous avons vu d'un peu plus près le protocole qui allait permettre à nos hôtes de se répartir les tâches dans le Fail-Over, Pfsense utilise également le protocole Pfsync dans son processus de mise en place du Fail-Over, Pfsync est un protocole utilisé pour synchroniser plusieurs machines exécutant le firewall Packet Filter, implémenté dans Pfsense.
Plus précisément, c'est par ce protocole que nous allons pouvoir gérer plusieurs hôtes via une seule interface, il fera en sorte par exemple de diffuser les états de connexion (fermée, ouverte, établies, ...) entre le routeur maître et les routeurs esclaves permettant ainsi une reprise des états de connexions en cas de panne du maître et de reprise de l'esclave. Pfsync est un des composants essentiels de la mise en place d'un haute disponibilité sous Pfsense.
Les messages pfsync sont envoyés en mulicast, il est recommandé de mettre une interface dédiée au pfsync par soucis de sécurité. En effet, en étant à l'écoute sur ce canal multicast, un pirate peut recevoir les messages de créations, de mise à jour et de suppression des états de connexions et pourrait même se faire passer pour un routeur en envoyant des paquets pfsync afin de perturber le bon fonctionnement du Fail-Over.
IV. Configuration
Nous allons maintenant passer à la mise en place et la configuration de notre Fail-Over. On suivra le schéma suivant :
Nous allons donc ici faire en sorte de mettre en Fail-Over nos deux Pfsense de manière à ce que si l'un tombe, l'autre prenne le relais. Il partageront une IP virtuelle que nous configurerons. Le Pfsense Maître sera "Pfsense 1" et le Pfsense Esclave sera le "Pfsense 2".
A. Ajout d'une interface Pfsync
Il est fortement recommandé, pour des raisons de sécurité comme indiqué un peu plus haut dans le tutoriel, de dédier un lien physique et une interface par hôte à la liaison pfsync. Nous allons donc, sur nos deux hôtes, suivre la procédure de création d'une interface que nous allons voir, pour la mise en place de ce nouveau lien, nous suivrons le schéma suivant :
On se rend donc sur l'interface d'administration de notre Pfsense 1, il faut alors aller dans "Interfaces" puis "assign" :
On va alors cliquer sur le petit formulaire avec un"+" qui va nous permettre d'ajouter une interface. Si cet icône n’apparaît pas, c'est que votre interface n'est pas détectée par le système, il faudra alors probablement le redémarrer :
Une fois cette opération effectuée, on pourra voir notre nouvelle interface (nommée "OPT1"), il faudra alors l'assigner à une interface physique, on identifiera cette interface par son adresse MAC ou par le numéro qui lui est affecté par rapport à ceux déjà attribués, une fois la sélection faite, il faut cliquer sur "Save" en bas du tableau :
Nous allons ensuite cliquer sur le nom de notre interface OPT1 pour la configurer. On va commencer par cocher la case "Enable Interface" puis nous allons saisir les champs "Description, sélectionner "Static IPv4" dans "IPv4 Configuration Type" et saisir l'IPv4 de notre interface dans la section "Static IPv4 Configuration" :
On validera en cliquant sur "Save" en bas de page. Par sécurité, Pfsense nous demande d'appliquer les changements, on cliquera donc sur "Apply changes" :
Cette procédure de création d'adresse est à répéter sur le deuxième Pfsense en adaptant l'IP bien entendu.
B. Activation de la synchronisation Pfsync
Maintenant que nos interfaces dédiées Pfsync sont prêtes, il va falloir les utiliser. On va pour cela aller dans "Firewall" puis dans "Virtual IPs" et enfin sélectionner l'onglet "CARP settings". Sur le maître et sur l'esclave, nous cocherons "Synchronize States". On va ensuite sélectionner "PFSYNC" comme interface de synchronisation ("Synchronize interface"), pour avoir un peu plus de sécurité, nous pourrons renseigner l'IP de l'interface Pfsync de l'hôte d'en face pour éviter les envois en multicast dans "pfsync Synchronize Peer IP".
Pour le bloc XMLRPC Sync, on va cocher pour les deux hôtes les cases suivantes :
- Synchronize Firewall Schedules
- Synchronize rules
- Synchronize NAT
- Synchronize aliases
- Synchronize NAT
- Synchronize Static Routes
- Synchronize Virtual IPs
- Synchronize traffic shaper(queues)
- Synchronize traffic shaper(limiter)
- Synchronize traffic shaper(layer7)
Cela va permettre au maître d'envoyer les informations de routages, de filtrage et de translation à son ou ses esclaves afin qu'ils les récupèrent en direct et en état si celui-ci a un dysfonctionnement. Enfin, uniquement sur le Maître, nous allons renseigner l'IP de l'interface pfsync de l'esclave dans "Synchronize Config to IP" ainsi que le login et mot de passe. Étant donné que c'est le maître qui se synchronise vers l'esclave et non l'inverse, ce dernier paramétrage n'est pas à effectuer sur l'esclave :
On cliquera bien sur "Save" en bas de page pour valider :
Nous allons maintenant passer à la création de notre IP virtuelle, dans notre cas ce sera 10.1.2.5/28. La configuration n'est a effectuer que sur le maître du cluster qui, via le lien pfsync établie précédemment, va ensuite diffuser la configuration à ses esclaves. On va aller dans "Firewall" puis dans "Virtual Ips" et on va cliquer sur le petit "+" à droite du tableau pour créer notre adresse virtuelle :
Ici, nous allons devoir choisir le protocole de synchronisation que nous souhaitons utiliser, CARP dans notre cas. Puis l'interface coté interface virtuelle, c'est à dire sur quel réseau va se situer l'IP virtuelle que nous souhaitons affecter au cluster, nous allons partir sur l'IP 10.1.2.5 qui sera donc du coté LAN, on sélectionnera donc "LAN" puis on saisira l'adresse IP virtuelle de notre cluster. On saisira également un mot de passe de groupe qui permettra de sécuriser les échanges ainsi qu'un numéro VHID (Virtual Host Identifier). On pourra également spécifier les valeurs de temps de synchronisation :
Par défaut, des règles sont mises en place pour bloquer certains trafics, étant donné que les liens Pfsync sont des interfaces uniquement dédiées à ce protocole, il ne sert à rien de mettre de filtrage particulier dessus (dans le cas d'une liaison non direct, on pourrait néanmoins l'envisager pour laisser passer uniquement le protocole Pfsync). On va donc se rendre dans "Firewall" puis dans "Rules" et on ira sélectionner l'interface "Pfsync" sur les deux hôtes :
On va ajouter une règle permettant de tout laisser passer, il faudra pour cela simplement s'assurer de sélectionner "Pass" dans le premier champ puis dans le bas du formulaire sélectionner "any" au niveau des ports :
V. Vérification
Une fois que ces deux règles seront en place, les hôtes vont commencer à échanger sur leurs états et le maître va envoyer la configuration à son esclave. On pourra donc, sur cet esclave, aller voir si les configurations faites sur le maître sont présentes. On va par exemple aller dans "Firewall" puis dans "Virtual IPs" pour voir que l’esclave à bien la configuration de l'IP virtuelle que nous avons configurée sur le maître :
Dans un second temps, on pourra sur le maître et sur l'esclave (aussi appelé "backup" dans pfsense) aller dans "Status" puis dans "CARP (Fail-Over)" pour voir que les rôles sont bien affectés, par exemple l'aperçu que l'on aura sur l'esclave :
Enfin, nous pouvons faire un test fonctionnel, nous allons pinguer l'IP virtuelle du cluster puis couper le Maître pour voir que l'IP virtuelle répond toujours et que l'esclave a bien pris le relais du cluster :
On voit donc la perte d'un paquet ICMP qui correspond au temps que le cluster met à réagir pour réaffecter le rôle de maître à l'esclave qui va alors gérer le trafic en attendant le retour du maître.
Article très intéressant. Curiosité, avec quel outil sont faits les diagrammes? Le style « main levée « est assez cool.
Merci ! Je fait les diagrammes avec Visio 2013, le style que j’utilise fait parti des style proposé par défaut.
Mickael;
Merci pour ce article , il est très intéressant mais je voudrais le télécharger en format pdf.
merci pour votre tuto !!
juste une question sur PFSYNC si vous permettez !! quels sont les contextes ou on peut s’en passer et ceux ou il est indispensable ?? merci d’avance
Bonjour lyes,
» Pfsync est un protocole utilisé pour synchroniser plusieurs machines exécutant le firewall Packet Filter »
Dés que tu veux synchroniser deux ou plusieurs Pare-feu tournant sur Packet Filter, tu doit utiliser le protocole PFsync. C’est lui qui permet le « dialogue » et l’échange d’infos entre plusieurs firewall packet filter. Ici on veut synchroniser nos règles de NAT ou de filtrage par exemple et celles-ci dépendent du pare feu. On doit donc utiliser Pfsync.
En espérant avoir répondu à ta question.
Bonjour,
Merci pour ce tuto qui ma permis d’y voir plus claire, et aussi de mettre en place ma config. 😉
Sans vouloir abuser j’ai une petite question:
La synchro. de la config. n’est pas bi-directionnelle? N’est pas ?
J’entends par la que :
en nominal, le paramétrage fait sur PF1 (master) est répliqué sur PF2.
quand PF1 tombe le PF2 deviens master.
a ce moment si le paramétrage est changé sur PF2 il n’est pas repris sur PF1 quand celui ci redeviens UP ?
Si je ne me trompe pas, y a il un moyen d’y remedier ?
Si je me trompe, 😉 comment on fait car ca marche pô chez moi …
Merci.
YMF
Sujet très intéressant… J’envisage clairement une telle solution, seulement j’ai quelques questions.
Si j’ai une ligne 10Mb et une autre à 2Mb, PFsense envoie 100% du trafic sur le WAN1 et quand il sature répartie sur le WAN2? Ou c’est directement 50% entre chaque ligne?
Merci de vos réponses
Bonjour,
De souvenir, il me semble qu’il s’agit uniquement de Fail-Over et non de Load-Balancing même si cela reste possible avec Pfsense. La décrite dans cet article précis concerne uniquement une mise ne place d’un Fail-Over. Autrement dit, tout passe par le serveur Pfsense 1 et seulement si celui-ci tombe, le second prend le relais pour l’intégralité des requêtes.
En espérant avoir répondu à votre question 🙂
Toujours aussi clair, merci du partage, continuez ainsi !
Bonjour,
Ayant bien suivi la procédure je n’ arrive pas à accéder à internet via l’ adresse IP virtuelle en passerelle, de plus la bonne règle NAT créer pouvoir créer la translation est introuvable.
bon jour j ai suivi le tutoriel mais quand j »ai créer les ip virtuelé et je mais » apply change » je perd la conection sur le maitre et puis les ip ne se diplique pas sur l ésclave .
Bonjour,
merci pour ce tuto très clair.
Par curiosité, comment est mis en place la partie Wan de ce schéma?
je comprends comment le LAN va utiliser le failover, mais qu’en est il du WAN ?
comment sont configurées les gateways dans ce cas précis?
Travaillez-vous avec des ip Alias sur chacune des interfaces Wan ?
Merci d’avance pour la réponse,
Olivier
Vos articles sur pfsense sont vraiment très intéressants et attractifs. Merci
Bonjour,
tout d’abord merci pour ceux tuto et tous les autres qui vraiment bien fait !
Je Dispose d’un serveur dédié (ESX 6 updates2) chez on-line dans le cadre d’un projet d’infrastructure en cours.
Au vu de la spécificité des Ip Fail over qui sont associés aux adresses Mac qui permettent la sortie vers le WAN grace à P. fsense.
Penses-tu qu’il est possible de faire un cluster PFsense en attribuant à cette Ip virtuelle (Cluster ou VIP) coté wan un des IP Failover dont je dispose .
Après un grand nombre de recherches je me questionne au niveau de l’activation du « promiscious mode ».
Merci de l’aide que quiconque pourra apporter,
Jérém.
merci pour ce tuto vous m’avais aidé
Un Nouveau tuto plus récent s’impose