Basculement CLUSTER non fonctionnel lors du retour du PFsense MASTER
-
Bonjour à tous,
Nous avons installé un cluster de PFSENSE dans le cadre d’une évolution d’une infrastructure de production.
Les 2 machines utilisées sont rigoureusement identique DELL R320
Nous avons installé dans chacune des machines une carte fibre dual port.Coté Interface
L’interface WAN est un LAGG des 2 interfaces fibres. le LAGG est configuré en LACP
Une interface physique à été configurée comme "LAN" que pour avoir un accès web, en temps normal, cette interface n’est pas câblée. Elle est utilisée qu'en cas de problème.
Nous avons créé des VLANs associés à l’interface LAGG.
L’interface LAGG reçoit à la fois des flux provenant de l’extérieur (interconnexion opérateur); elle véhicule aussi des flux interne (inter-VLANs).
Une interface physique des serveurs a été dédiée pour la synchronisation PFSYNC pour la synchronisation du cluster avec mise en place des règles nécessaire pour assurer la synchronisation des 2 pfsenses.
Nous avons créé des interfaces associées aux VLANs
• Sur le MASTER : IP1
• Sur le SLAVE : IP2
• Sur le master nous avons créé une CARP associé aux interfaces avec une IP3.
Nous avons plus de 15 CARPs de configurées en IPV4 et IPV6Coté Service
Nous utilisons les 2 pfsenses pour
• Serveur IPSEC
• Serveur DHCP (pour quelques VLANs)
• Serveur DNS resolver
• Serveur NTPAfin de simplifier les règles de filtrages nous avons créé des "interfaces groups" afin de regrouper les VLANs de même type (LAN bureautique, LAN administration financière, interco, etc ..). Des règles de filtrage ont été mise en place sur les « interface groups »
Pour le NAT nous avons utilisé du NAT OUTBOUND ( Hybrid Outbound NAT rule generation)
Version des Pfsenses
Les 2 pfsenses ont été installée en version 2.2.3.
Nous n’avons ajouté aucun package supplémentaires.Notre problème :
En fonctionnement normal :
Le MASTER rempli son rôle, Les CARPs sont MASTER, le trafic passe par lui, les serveurs DHCPs, DNS, IPSEC etc sont tous fonctionnel.
Le SLAVE est en attente avec les CARPs en BACKUP.On coupe le PFSENSE MASTER : le SLAVE prend la main, les CARPs basculent MASTER, les serveurs DHCP, DNS, IPSEC etc .. basculent sans problème. Le temps de la bascule on perd 3 pings vers les interconnexions de transit. –> tout vas bien !
On relance le PFSENSE MASTER : les CARPs reviennent MASTER sur le Pfsense MASTER, et bascule en BACKUP sur le Pfsense SLAVE. Mais la bascule semble n’être que visuelle; a ce moment là, on perd toutes connectivité vers l’extérieur, le serveur IPSEC tombe, etc …
En effectuant une recherche ARP, on constate que les requêtes partent toujours vers le SLAVE.
Le reboot du Pfsense SLAVE permet au PFsense MASTER de reprendre totalement la main, et rendre à nouveau le service ( interco, IPSEC etc .. )
Nous avons essayé de resetter complètement le Pfsense SLAVE, (à travers le menu CLI : 4 reset to factory default), réinstaller les interfaces à la main, récréer les liens PFSYNC, etc ..
Une fois la synchronisation effectuée entre les 2 PFsenses, nous avons toujours constaté le problème.Quelqu'un aurait une piste de recherche ?
Merci d'avance pour votre aide.--
Thierry -
Ça nous change un message initial où l'on des données pour comprendre la configuration !
Des informations dans les logs de Pfsense ? -
Bonjour,
Voici ce que j'ai pu trouver sur le SLAVE
Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan990 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan680 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan884 Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan991 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan358 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan530 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan885 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan357 Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan529 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan886 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan871 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan887 Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan356 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan528 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan870 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan880 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan519 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan881 Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan984 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan532 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan997 Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan982 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan522 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan996 Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan983 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan523 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan520 Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan981 Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan993 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan89 Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan676 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan526 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan873 Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan992 Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan677 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan527 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan872 Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan995 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan678 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan524 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan875 Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan994 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan15 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan679 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan525 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan874 Aug 7 18:19:00 pfSense check_reload_status: Carp backup event Aug 7 18:19:00 pfSense check_reload_status: Linkup starting lagg0_vlan480 Aug 7 18:19:01 pfSense php-fpm[31757]: /rc.linkup: Hotplug event detected for WAN(wan) but ignoring since interface is configured with static IP ( ) Aug 7 18:19:01 pfSense check_reload_status: rc.newwanip starting lagg0 Aug 7 18:19:01 pfSense php-fpm[31757]: /rc.carpbackup: Carp cluster member "194.199.220.17 - IP Virtuelle FailOver VLAN990 (55@lagg0_vlan990)" has resumed the state "BACKUP" for vhid 55@lagg0_vlan990 Aug 7 18:19:01 pfSense php-fpm[31757]: /rc.linkup: Hotplug event detected for VLAN990(opt38) but ignoring since interface is configured with static IP (194.199.220.20 ) Aug 7 18:19:01 pfSense check_reload_status: rc.newwanip starting lagg0_vlan990 Aug 7 18:19:01 pfSense php-fpm[55763]: /rc.linkup: Hotplug event detected for VLAN680(opt28) but ignoring since interface is configured with static IP (192.168.103.253 ) Aug 7 18:19:01 pfSense check_reload_status: rc.newwanip starting lagg0_vlan680 Aug 7 18:19:01 pfSense php-fpm[31757]: /rc.carpbackup: Carp cluster member "192.168.103.254 - IP Virtuelle FailOver VLAN680 (42@lagg0_vlan680)" has resumed the state "BACKUP" for vhid 42@lagg0_vlan680 Aug 7 18:19:01 pfSense php-fpm[31757]: /rc.linkup: Hotplug event detected for VLAN884(opt17) but ignoring since interface is configured with static IP (10.117.17.252 ) Aug 7 18:19:01 pfSense check_reload_status: rc.newwanip starting lagg0_vlan884 Aug 7 18:19:01 pfSense php-fpm[55763]: /rc.carpbackup: Carp cluster member "10.117.17.250 - IP Virtuelle FailOver VLAN884 (19@lagg0_vlan884)" has resumed the state "BACKUP" for vhid 19@lagg0_vlan884 Aug 7 18:19:01 pfSense php-fpm[31757]: /rc.linkup: Hotplug event detected for VLAN358(opt32) but ignoring since interface is configured with static IP (192.168.100.239 ) Aug 7 18:19:01 pfSense check_reload_status: rc.newwanip starting lagg0_vlan358 Aug 7 18:19:01 pfSense php-fpm[55763]: /rc.carpbackup: Carp cluster member "192.168.100.240 - IP Virtuelle FailOver VLAN358 (46@lagg0_vlan358)" has resumed the state "BACKUP" for vhid 46@lagg0_vlan358 Aug 7 18:19:01 pfSense php-fpm[31757]: /rc.carpbackup: Carp cluster member "194.199.220.124 - Ip FailOver VLAN530 (56@lagg0_vlan530)" has resumed the state "BACKUP" for vhid 56@lagg0_vlan530 Aug 7 18:19:01 pfSense php-fpm[31757]: /rc.linkup: Hotplug event detected for VLAN530(opt21) but ignoring since interface is configured with static IP (194.199.220.125 2001:660:302d:4011::1) Aug 7 18:19:01 pfSense php-fpm[55763]: /rc.carpbackup: Carp cluster member "2001:660:302d:4011::10 - IPv6 FailOver VLAN530 (57@lagg0_vlan530)" has resumed the state "BACKUP" for vhid 57@lagg0_vlan530 Aug 7 18:19:01 pfSense check_reload_status: rc.newwanip starting lagg0_vlan530 Aug 7 18:19:01 pfSense php-fpm[31757]: /rc.linkup: Hotplug event detected for VLAN885(opt18) but ignoring since interface is configured with static IP (10.117.41.252 ) Aug 7 18:19:01 pfSense check_reload_status: rc.newwanip starting lagg0_vlan885 Aug 7 18:19:01 pfSense php-fpm[55763]: /rc.carpbackup: Carp cluster member "10.117.41.250 - IP Virtuelle FailOver VLAN885 (20@lagg0_vlan885)" has resumed the state "BACKUP" for vhid 20@lagg0_vlan885 Aug 7 18:19:01 pfSense php-fpm[31757]: /rc.carpbackup: Carp cluster member "10.217.255.250 - IP Virtuelle FailOver VLAN357 (3@lagg0_vlan357)" has resumed the state "BACKUP" for vhid 3@lagg0_vlan357 Aug 7 18:19:01 pfSense php-fpm[55763]: /rc.carpbackup: Carp cluster member "2001:660:302d:4357::1:1 - IPV6 Virtuelle FailOver VLAN357 (32@lagg0_vlan357)" has resumed the state "BACKUP" for vhid 32@lagg0_vlan357 Aug 7 18:19:01 pfSense php-fpm[31757]: /rc.linkup: Hotplug event detected for VLAN357(opt2) but ignoring since interface is configured with static IP (10.217.255.252 2001:660:302d:4357::1) Aug 7 18:19:01 pfSense check_reload_status: rc.newwanip starting lagg0_vlan357 Aug 7 18:19:01 pfSense php-fpm[55763]: /rc.linkup: Hotplug event detected for VLAN886(opt19) but ignoring since interface is configured with static IP (10.255.255.252 ) Aug 7 18:19:01 pfSense check_reload_status: rc.newwanip starting lagg0_vlan886 Aug 7 18:19:01 pfSense php-fpm[31757]: /rc.carpbackup: Carp cluster member "10.255.255.250 - IP Virtuelle FailOver VLAN886 (3@lagg0_vlan886)" has resumed the state "BACKUP" for vhid 3@lagg0_vlan886 Aug 7 18:19:01 pfSense php-fpm[31757]: /rc.linkup: Hotplug event detected for VLAN871(opt10) but ignoring since interface is configured with static IP (10.117.25.62 ) Aug 7 18:19:01 pfSense check_reload_status: rc.newwanip starting lagg0_vlan871 Aug 7 18:19:01 pfSense php-fpm[55763]: /rc.carpbackup: Carp cluster member "10.117.25.60 - IP Virtuelle FailOver VLAN871 (27@lagg0_vlan871)" has resumed the state "BACKUP" for vhid 27@lagg0_vlan871 Aug 7 18:19:18 pfSense php-fpm[55763]: /rc.carpmaster: Carp cluster member "192.168.100.240 - IP Virtuelle FailOver VLAN358 (46@lagg0_vlan358)" has resumed the state "MASTER" for vhid 46@lagg0_vlan358 Aug 7 18:19:22 pfSense check_reload_status: updating dyndns GW_VLAN996 Aug 7 18:19:22 pfSense check_reload_status: Restarting ipsec tunnels Aug 7 18:19:22 pfSense check_reload_status: Restarting OpenVPN tunnels/interfaces Aug 7 18:19:34 pfSense php-fpm[31757]: /rc.newipsecdns: IPSEC: One or more IPsec tunnel endpoints has changed its IP. Refreshing. Aug 7 18:19:34 pfSense check_reload_status: Reloading filter Aug 7 18:19:34 pfSense php-fpm[31757]: /rc.newipsecdns: WARNING: Setting i_dont_care_about_security_and_use_aggressive_mode_psk option because a phase 1 is configured using aggressive mode with pre-shared keys. This is not a secure configuration. Aug 7 18:19:34 pfSense php-fpm[31757]: /rc.newipsecdns: Forcefully reloading IPsec Aug 7 18:19:34 pfSense check_reload_status: Reloading filter Aug 7 18:19:34 pfSense php-fpm[31757]: /rc.newipsecdns: WARNING: Setting i_dont_care_about_security_and_use_aggressive_mode_psk option because a phase 1 is configured using aggressive mode with pre-shared keys. This is not a secure configuration. Aug 7 18:19:38 pfSense php-fpm[69294]: /rc.newipsecdns: IPSEC: One or more IPsec tunnel endpoints has changed its IP. Refreshing. Aug 7 18:19:38 pfSense check_reload_status: Reloading filter Aug 7 18:19:38 pfSense php-fpm[69294]: /rc.newipsecdns: WARNING: Setting i_dont_care_about_security_and_use_aggressive_mode_psk option because a phase 1 is configured using aggressive mode with pre-shared keys. This is not a secure configuration. Aug 7 18:19:38 pfSense php-fpm[69294]: /rc.newipsecdns: Forcefully reloading IPsec Aug 7 18:19:38 pfSense check_reload_status: Reloading filter Aug 7 18:19:38 pfSense php-fpm[69294]: /rc.newipsecdns: WARNING: Setting i_dont_care_about_security_and_use_aggressive_mode_psk option because a phase 1 is configured using aggressive mode with pre-shared keys. This is not a secure configuration. Aug 7 18:21:34 pfSense login: login on ttyv0 as root Aug 7 18:21:38 pfSense check_reload_status: Linkup starting bge1 Aug 7 18:21:38 pfSense kernel: bge1: link state changed to DOWN Aug 7 18:21:39 pfSense php-fpm[28220]: /rc.linkup: Hotplug event detected for LAN(lan) but ignoring since interface is configured with static IP (192.168.1.2 ) -
Bonjour,
Peux-tu nous indiquer la configuration de tes @VIP CARP ?
Notamment les valeurs de "advbase" et "advskew" pour le master et pour le slave ? -
Bonjour,
Voici un exemple de configuration sortie du fichier de conf du PF MASTER
<vip><mode>carp</mode> <interface>opt35</interface> <vhid>37</vhid> <advskew>0</advskew> <advbase>1</advbase> <password>je_vous_le_donne_pas</password> <type>single</type> <subnet_bits>29</subnet_bits> <subnet>192.168.20.4</subnet></vip>Concernant les valeurs "advbase" et "advskew" :
Sur le MASTER<advskew>0</advskew> <advbase>1</advbase>Sur le SLAVE
<advskew>100</advskew> <advbase>1</advbase>Lors de la création des CARPs à travers l'interface web de configuration, nous n'avons pas touchées à ces valeurs. Il me semble de PFSENSE s'occupe lui même de les ajuster.
–
Thierry -
-
Je pense qu'il va falloir poster d'avantage d'éléments sur votre configuration. Je vois opt38 dans les logs … ce qui laisse supposer une configuration complexe avec beaucoup de vlans ....
-
si je résume :
- CARP fonctionne bien car les noeuds se voient et les VIP basculent aller /retour
- pfSync fonctionne a priori car vous ne semblez pas constater de drop des sessions TCP en cours durant une bascule ( vous ne le dite pas mais vous l'auriez constaté)
Quel est le type d'equipement reseau ?
Pouvez vous faire un tcpdump sur l'interface du maitre quand ce produit le phenomene ? l'objectif etant de voir si il recoit les arp-who-has.
Si il les recoit et qu'il ne repond pas (alors qu'il devrait), il faudra investiguer cote freeBSd du serveur maitre. -
Le CARP fonctionne coté PFSENSE.
il fallait en effet regarder du coté de FREEBSD …Lorsque l'équipement MASTER disparait (perte de connexion, reboot) l'équipement SLAVE constate la bascule et reprends les adresses CARP, les équipements réseaux adaptent les tables ARP (passage à l'état inactif des interfaces sur l'équipement MASTER) et le service est toujours rendu.
Mais lorsque le MASTER revient à la vie, le SLAVE, ne perdant pas la connection réseau, le routeur continue à penser que le SLAVE est MASTER.
L'une des solution pour provoquer la mise à jour de la table ARP du routeur, a été de rebooter le SLAVE (passage des interfaces physique à DOWN) pour provoquer le flapping des interfaces réseaux. L'autre solution consiste à faire un clear de la table ARP des routeurs.C’est en faisant des TCPDUMPs que nous avons constaté en faite que le PFSENSE ne faisait pas de gratuitous ARP lors de la bascule CARP du SLAVE au MASTER.
Pour pouvoir forcer ces annonces, nous avons
- installer le package ARPING sur les PFSENSES
- modifier le script /etc/rc.carpmaster pour y intégrer la commande : /usr/local/sbin/arping -C 5 -i moninterface -S monadressesource monadresssdestination
au reboot, le master préviens le switch qu’il est là …. la table ARP se mets à jour, et le basculement du réseau est opérationnel.
Est-ce le comportement normal d'un cluster de PfSense ? Quelqu'un a-t-il déjà rencontré ce problème ?