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 IPV6

    Coté Service
    Nous utilisons les 2 pfsenses pour
    • Serveur IPSEC
    • Serveur DHCP (pour quelques VLANs)
    • Serveur DNS resolver
    • Serveur NTP

    Afin 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



  • Bonjour à tous,

    Personne n'a une idée ? une piste de réflexion ? un soupçon de … je sais pas moins ... quelques choses ?

    Bien Cordialement

    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 ?