Cluster de Pfsense (VIP CARP)

2 pare-feux pfsense en "cluster"

Qu'est-ce que cela veut dire ?
C'est simple : Quand l'un tombe en panne (le master), le second (le backup) prend le relai, et continue à la fois de router les paquets, et d'assurer la sécurité du réseau, sans qu'il n'y ait besoin d'intervention humaine.
Un seul des 2 pares-feux joue le rôle de master en permanence. Il n'y a qu'un pare-feu qui travaille (sur les 2).
Mais dès lors qu'il tombe en panne, le second prend le relai immédiatement.

Cela suppose que ces 2 pfsense (appelons-les PFSENSE01 et PFSENSE02) doivent répondre sur une adresse IP commune (une "VIP", pas une Very Important IP, mais pas loin .. une Virtual IP), que ce soit côté WAN ou côté LAN.

La mise en cluster des PF est extrêmement simple, mais de grâce, lisez ATTENTIVEMENT ce que j'écris !
ça vous évitera un paquet d'em*****...
Le schéma doit être parfaitement maîtrisé.

Un petit schéma pour voir ce qu'on va faire :

Internet arrive par le côté WAN (qui ici, passe d'abord par un réseau non routable, pour les besoins du TP).
Les 2 pares-feux PFSENSE01 et PFSENSE02 vont donc permettre d'isoler le réseau LAN comme on isolerait le réseau LAN de l'entreprise (de façon simpliste ! c'est un TP !!)

Pour les besoins de la mise en cluster  :
1) chaque pare-feu doit avoir, a minima, 3 cartes réseaux :
- une interface côté WAN (WAN). 
- une interface côté LAN (LAN)
- et une interface de synchronisation entre les 2 pare-feux (PFSYNC)

Cette dernière est très importante pour augmenter la sécurité et la rapidité des échanges entre les 2 pares-feux.
On pourrait parfaitement s'en passer, mais ce n'est pas recommandé.

A savoir, vous pouvez (dans le cadre du TP) utiliser un DHCP pour vos interfaces des PF côté WAN, mais vous devrez en revanche impérativement pouvoir disposer d'une IP statique pour les VIP côté WAN et LAN !
Les VIP ne s'adressent pas via DHCP, c'est du statique.

Sur l'hyperviseur, nous parlerons de commutateurs virtuels.
Il faut donc 3 commutateurs virtuels, auxquels seront attachées les interfaces de nos pares-feux.
- COM_EXT (un commutateur "externe") qui est ponté sur la carte réseau physique de notre hyperviseur
- COM_LAN (un commutateur "interne"), qui servira à relier notre CLIENT dans le LAN ainsi que les PF
- COM_PFSYNC (un commutateur "interne" ou "privé") pour relier nos 2 PF et uniquement eux.

2) L'usurpation d'adresse MAC (MAC spoofing) DOIT IMPERATIVEMENT ETRE PERMISE SUR LES INTERFACES WAN ET LAN DE CHACUN DES PARES-FEUX.
Si vous n'activez pas cette fonctionnalité sur votre hyperviseur, la mise en cluster ne fonctionnera tout simplement pas !
Si vous êtes sur Hyper-V, voici où ça se situe :

(Je répète que cette opération doit être réalisée sur les interfaces WAN et LAN de chacun des pares-feux !)

 Sur VMWare Workstation, cette opération n'est pas nécessaire.

Commençons !

1) Créez vos VM, configurez leurs interfaces et adressages IP tel que le précise le schéma.
N'oubliez pas de configurer votre CLIENT, car c'est grâce à lui que nous accéderons aux consoles Web des PF.
Dans un premier temps, mettez lui l'IP de PFSENSE01 comme passerelle. Nous changerons cela à la fin du tuto.

2) Configurez les interfaces des PF en CLI :
- Pour rappel, on commence d'abord par assigner les interfaces (1), puis on paramètre les configurations IP (2) pour chaque interface. (A titre perso, je préfère le faire ainsi, ça va beaucoup plus vite que via la console web)

Voici ce que vous devez obtenir :

3) Depuis votre CLIENT, connectez vous à la console des 2 PFSENSE, côte à côte (prenez cette habitude !) !
(passez les avertissements de sécurité SSL usuels)

Entrez les identifiants par défaut de pfsense : admin/pfsense

- Faîtes la configuration du wizard de base sur les 2 PF :

Libre à vous de mettre autre chose que CloudFlare (1.1.1.1) mais pensez à bien entrer un hostname différent sur chaque PF

(Notre WAN dans ce TP est un réseau non routable (192.168.1.0/24), donc il faut décocher la RFC1918)

(je ne change pas le mot de passe admin pour ce TP... bien entendu, vous le ferez en vrai !)

- Nous voici sur le Dashboard. On va pouvoir commencer la configuration.

4) Configurer les VIP 

- Nous allons créer la VIP côté WAN. Cette VIP aura l'IP 192.168.1.246.
Bien entendu, cette IP doit être libre (et ne pas figurer sur une étendue DHCP... par exemple).

Pour créer une VIP commune aux 2 PF, PFsense va créer un groupe VHID.
Ce VHID doit évidement être le même sur les 2 PF pour la même VIP.

Il faut créer un mot de passe pour ce groupe VHID 1, et mettre le même sur les 2 PF !
(d'où l'intérêt de la configuration des 2 côtés en même temps !).
Prenez soin de ne pas mettre de caractères spéciaux ou d'espaces dans les mots de passe.. ça pose régulièrement des problèmes sur pfsense.

A noter : le skew !! C'est lui qui détermine qui jouera le rôle du master, et qui jouera le rôle du backup !
Le master doit avoir le skew le plus bas (0). Ici, nous alternerons simplement entre 0 et 1.
PFSENSE01 (à gauche) sera donc le master !
PFSENSE02 (à droite) sera donc le backup

Inutile d'appliquer les changements tout de suite, créez tout de suite votre seconde VIP (côté LAN).

- même topo pour la VIP du côté LAN. A ceci près que le VHID n'est plus le même que sur la VIP WAN ! (logique) et que vous avez pris soin de choisir l'interface LAN.

Pour le skew : on ne s'amuse pas à changer de rôle selon une VIP ou l'autre ! 
Nous avions décrété que PFSENSE01 serait le master, donc on remet le skew à 0 pour PFSENSE01 et à 1 pour PFSENSE02.

- Appliquez à présent les changements.

- Les VIP sont à présent configurées.

5) Configurer l'interface de Synchronisation
Comme la configuration a été effectuée au tout début en CLI, nous allons simplement la renommer plutôt que de garder le nom de la première interface optionnelle (OPT1) par défaut de pfsense.

- Changez simplement la description puis descendez tout en bas pour sauvegarder, puis appliquez la configuration.

6) Configurer le cluster
Nous devons maintenant expliquer aux PF comment ils devront communiquer leurs informations de statut et les services configurés
Attention, la configuration n'est pas la même sur les 2 nœuds !

- Cocher la synchronisation des états sur les 2 nœuds.
- Sélectionnez l'interface PFSYNC pour la communication entre les 2 PF
- Indiquez l'adresse IP de l'autre nœud (réciproquement) dans le champs "pfsync Synchronize Peer IP"
- Indiquez l'IP de PFSENSE02 dans le champs "Synchronize Config to IP" sur PFSENSE01 et RIEN SUR PFENSE02 !
- Idem utilisateur et mot de passe (les identifiants par défaut de pfsense : admin/pfsense) , QUE SUR PFSENSE01 (le master)

- Cochez la synchronisation des identifiants admin, puis cliquez sur "Toggle All" en bas pour sélectionner tous les services à synchroniser d'un coup (ou choisissez uniquement ce que vous voulez synchroniser !)

La validation prend plus de temps sur PFSENSE02 que sur PFSENSE01, c'est normal. Patientez.
A l'issue de la sauvegarde, vous voici de retour en haut de la page

7) Visualisez le statut CARP

Vous pouvez constater que chaque PF a bien son statut. PFSENSE01 est le master, PFSENSE02 est en backup.
La configuration de la redondance CARP est terminée.

Si vous coupez PFSENSE01, vous verrez que PFSENSE02 deviendra le master.

8) Règle de pare-feu sur PFSYNC :
Il nous reste une règle de pare-feu à mettre en place sur l'interface PFSYNC pour permettre la réplication automatique de configuration de PFSENSE01 sur PFSENSE02 (Il vous suffira après cela, de ne configurer que PFSENSE01, et les règles se dupliqueront sur le 2 automatiquement).

Voilà.
A présent, XMLRPC va pouvoir répliquer les configurations de PFSENSE01 sur PFSENSE02.

Le meilleur moyen de le tester, c'est de créer une règle à la noix ou de faire un DNAT redirection de ports sur PFSENSE01 et de regarder tout de suite après l'application, si la règle est bien répliquée...
Exemple ici, avec un DNAT rdp sur PFSENSE01... répliqué aussitôt appliqué sur PFSENSE02 :

9) Indiquez la VIP LAN en tant que nouvelle passerelle pour le réseau LAN.
Configurez l'adressage IP de votre CLIENT, afin que la passerelle soit désormais la VIP LAN (10.10.10.3)

Le tuto est terminé....
Mais la configuration du cluster peut aller BEAUCOUP plus loin... Je vous laisse explorer.