pfSense: création d’un cluster

Mise en place d’un cluster de deux routeurs/pare-feux pfSense.

Après un petit mois sans article, j’ai décidé de recommencer tranquillement avec un premier article traitant de pfSense ! Ici nous allons voir comment monter un cluster de deux hôtes pfSense dans le but de réaliser du Failover, et ce premier lab me permettra de rédiger d’autres articles qui suivront, et qui se situeront toujours dans ce lab.

Sans plus tarder, commençons !

I) Cluster, Failover… un petit rappel ?

Vous commencez à avoir l’habitude, j’aime bien d’abord redéfinir un peu de quoi on parle avant de se lancer tête baissée. Du coup, un petit rappel s’impose !

Mais tout d’abord, voici notre topologie :

Nous aurons donc notre WAN, qui sera en réalité mon routeur/modem physique, puis ensuite nos deux machines virtuelles pfSense, avec pour :

• pfSense-01 :
  • Une IP WAN en : 192.168.1.51/24
  • Une IP LAN en : 192.168.2.254/24
  • Une IP virtuelle pour le WAN en : 192.168.1.100/24
  • Une IP virtuelle pour le LAN en : 192.168.2.250/24

• pfSense-02 :
  • Une IP WAN en : 192.168.1.52/24
  • Une IP LAN en : 192.168.2.253/24
  • Une IP virtuelle pour le WAN en : 192.168.1.100/24
  • Une IP virtuelle pour le LAN en : 192.168.2.250/24

Le but du Failover, c’est donc de faire en sorte que si mon pfSense-01 venait à tomber, le 02 prendrait le relais, jusque là nous sommes d’accord. Mais il faudra aussi utiliser deux adresses IP virtuelles ; une pour le LAN, et une pour le WAN. De cette manière, sur nos clients, nous ne leur communiquerons que les IP virtuelles et non les IP locales de nos pfSenses, pour que si l’un des deux venait à tomber, l’IP en question soit toujours joignable.

Pour cela, il existe le protocole CARP, pour Common Address Redundancy Protocol, littérallement Protocole de redondance d’adresses communes. Le titre est assez clair, ce protocole permet à plusieurs hôtes d’utiliser une même IP pour effectuer de la redondance.

Ensuite, nous utiliserons les protocoles pfSync et XML-RPC, qui permettent respectivement de synchroniser l’état des connexions en cours entre deux hôtes pfSense et pour le second de répliquer la configuration.

Côté Vmware Workstation, car c’est via cet hyperviseur que je réalise ce lab, j’ai usé des fameux LAN Segments, et chaque VM pfSense aura donc :

• Une interface en Bridge, qui correspondra au WAN ;
• Une interface en Lan Segment nommé “LAN” ;
• Une interface en Lan Segment nommé “pfSync” ;

On ne fait pas plus clair 😉

Pour les protocoles pfSync et XML-RPC, comme pour pas mal d’autres protocoles de load-balancing/clustering, il est toujours préférable d’avoir une interface et un lien dédié (voir plusieurs) pour n’y faire transiter que ce trafic, mais si dans votre cas ce n’est pas possible, on peut toujours utiliser l’interface LAN sans soucis.

Bien, maintenant que l’on sait vers quoi on s’attarde, passe à la pratique !

II) Mise en place des interfaces virtuelles

Je pars du principe que vous avez vos deux pfSense installés et configurés, c’est assez trivial et j’ai déjà fait plusieurs articles dessus.

La première étape est donc de créer nos deux interfaces virtuelles, sur chacun de nos hôtes. Pour cela on se rend sur Firewall puis Virtual IPs puis Add :

Ici on choisi donc le type CARP, car nous avons aussi la possibilité d’utiliser l’IP Alias ou encore le Proxy ARP, mais ce n’est pas le cas ici. On choisi ensuite notre interface, WAN pour commencer, puis on renseigne donc notre adresse. Ensuite, on renseigne un mot de passe qui sera utilisé pour le groupe VHID. On vient ensuite justement renseigner l’ID de ce fameux groupe, car un même pfSense peut faire parti de plusieurs clusters, ici nous nous contenterons de l’ID 1. Et enfin, nous laissons la valeur Base à 1 (qui correspond au nombre de secondes avant qu’un hôte soit considéré comme down) et pour la valeur Skew, nous la laissons à valeur à 0. Cette valeur devra être incrémentée sur chacun des “esclaves” de notre cluster, ici nous sommes sur notre pfSense-01 qui sera le master donc nous laissons cette valeur.

Libre à vous de mettre ensuite une description ou non, puis nous réalisons la même chose pour l’IP virtuelle du LAN :

Normalement, si l’on se rend sur l’onglet Status puis CARP (failover) on devrait avoir ceci, après avoir réalisé la même manipulation sur le second pfSense :

Et pour le second :

Nous avons bien un Master, et un second en Backup. Parfait !

Ensuite nous devons dire à pfSense d’utiliser plutôt l’IP Virtuelle nouvellement créee plutôt que d’utiliser son IP LAN/WAN classique. Pour cela, on se rend dans Firewall puis NAT.

On choisi l’option Hybrid Outbound NAT plutôt qu’Automatic Outbound NAT, de cette manière nous allons pouvoir créer une règle qui sera prise en compte en cliquant sur Add juste en dessous de Mappings :

Ici, on choisi donc notre interface WAN, car c’est sur celle-ci que s’opère le NAT pour rappel, puis nous choisissons Any comme protocole, comme source nous prenons notre réseau LAN donc ici ce sera 192.168.2.0/24, et enfin en dessous dans Address nous choisissons notre interface virtuelle WAN créée précédemment.

Comme d’habitude, une petite description ne fait pas de mal.

On peut ensuite soit répliquer cette configuration sur notre second pfSense, soit attendre un peu plus tard dans cet article quand nous activerons la réplication de configuration, au choix.

P.S: ici je ne traiterai pas de la configuration à modifier pour les protocoles VPN (OpenVPN, IPSec), mais il en va de même pour le DHCP par exemple: pensez à bien modifier l’IP du WAN/LAN par celle de la VIP !

III) Mise en place de la High-Availability

Bien, désormais nous allons nous attaquer à la partie synchronisation de configurations entre nos deux hôtes.

La première étape est d’activer notre interface “pfSync”.

Pour cela, on se rend d’abord sur Interfaces, puis Assignments :

On va donc cliquer sur Add pour rajouter notre interface :

On coche bien entendu la case Enable, puis on rajoute la description qui va bien, on lui assigne une adresse IP (dans mon cas ce sera en /30, car je n’ai que deux hôtes mais libre à vous d’adapter au besoin), et c’est à peu près tout. Pensez à faire de même sur le second pfSense en ajustant l’adresse IP et le tour est joué !

Ensuite, on se rend dans System, puis High Avail. Sync :

On coche la case Synchronize states, qui permet d’activer la fonctionnalité, on choisi ensuite notre interface (LAN ou bien une interface dédiée, dans notre cas ce sera donc pfSync), on défini ensuite l’IP de notre second pfSense (pour rappel, toutes les actions effectuées jusqu’ici sont réalisées sur le pfSense-01 !), et ensuite on renseigne à nouveau l’IP du second dans le champ Synchronize Config to IP, puis on ajoute plus bas les credentials et enfin on coche les fonctionnalités à répliquer. Pensez à cocher NAT configuration, de cette manière vous pourrez voir par la suite si vos démarches fonctionnent en vous rendant sur le second pfSense.

Par rapport au second pfSense justement, il convient simplement de cocher la case pour activer le service, renseigner l’interface, puis l’IP du pfSense-01 dans pfsync Synchroniez Peer IP et rien de plus, car c’est le Master qui va répliquer les sur les slaves pour rappel 😛

IV) Les règles de pare-feu

Car oui, c’est bien beau tout ça, mais vous vous rendrez vite compte que même en tapant dessus çe ne fonctionner pas… et oui, par défaut les interfaces sur pfSense bloquent tout le trafic, donc nous devons nous rendre sur l’onglet Firewall puis Rules et enfin pfSync (ou local) pour rajouter nos règles de pare-feu histoire d’autoriser ce trafic.

Ici, c’est un peu à vous de voir, en fin presque, je m’explique: pour la synchronisation via le protocole XML-RPC, normalement celle-ci s’effectue sur le port 443, et pour le pfSync, une option lui est dédiée dans la partie Protocol, le soucis est que personnellement, à l’heure où j’écris ces lignes, je n’ai pas réussi à faire fonctionner la synchro’ en ouvrant seulement ces ports… et j’avoue avoir la flemme de chercher pour le moment haha, donc ici j’autorise tout le trafic.

Avec cette configuration, tout fonctionne, même si bien entendu ce n’est pas à faire en production, encore qu’ici nos pfSense sont comme “connectés en direct l’un sur l’autre”, donc aucun risque ou presque (car le risque zéro n’existe pas etc etc).

Breeef, on autorise le trafic sur notre pfSense-01 ainsi que sur le second, et c’est bon !

V) Le classique reboot, et le test !

Une fois tout ceci effectué, redémarrez vos deux pfSense, et normalement tout devrait être bon !

Pour ce faire, on peut effectuer un “ping 192.168.1.100 -t” et regarder ce qui se passe quand notre pfSense-01 est hors-ligne :

Bon, là comme ça vous allez devoir me croire sur parole, mais je peux vous assurer qu’il n’y pas un seul ping de perdu lors du basculement !

On peut aussi se rendre sur le pfSense-02 et voir dans la rubrique NAT si la configuration du premier s’est bien répliquée :

Bon, j’avoue, à vous de me croire encore une fois mais c’était bien le cas !

Nous avons donc un petit cluster de deux nodes pfSense entièrement fonctionnel ! Comme dit en début d’article cet article me permettra d’embrayer sur plusieurs autres où je parlerais de WSUS, TrueNAS, et aussi d’un cluster K8S/K3S via Packer/Terraform/Ansible/CloudInit sur ESXi… bref, de jolies choses en somme !

VI) Conclusion

Je tiens d’abord à remercier le site provya.net qui m’aura bien aidé pour la rédaction de cet article. Pour moi c’est un peu comme une “v2” de leur article posté il y a quand même 4 ans, avec (je l’espère) un poil plus d’explications/plus de fraîcheur 😅

Je tiens aussi à m’excuser du manque d’article pendant ce mois de janvier, mais changement professionnel oblige : mon CDD se terminant le 31, j’ai dû réglé quelques affaires personnelles et j’avais donc moins de temps à consacrer au blog, mais étant donc de facto en pleine recherche d’emplois, ce blog va carburer ! (Du moins, en théorie haha).

Sur ce, je vous souhaite une bonne journée/soirée, et j’espère comme à mon habitue vous avoir appris quelques bricoles !