Provya

Sécurité et téléphonie

Articles & Tutoriaux  -  Liens & Actualités

[pfSense] Configurer un cluster de 2 pfSense redondants (failover)

icon 02/10/2016

Dans cet article, nous allons voir comment configurer deux serveurs pfSense en mode cluster afin d'assurer un service en haute-disponibilité.

Il est à noter que pfSense est l'une des rares solutions open-source offrant des techniques de haute-disponibilité permettant de garantir que le firewall ne puisse pas être un point individuel de défaillance (SPOF).

Dans cet article, nous nous baserons sur l'architecture suivante pour réaliser nos configurations :


pfSenseA - WAN : 172.25.46.101
pfSenseB - WAN : 172.25.46.102
@IP virtuelle - WAN : 172.25.46.100

pfSenseA - LAN : 192.168.0.11
pfSenseB - LAN : 192.168.0.12
@IP virtuelle LAN : 192.168.0.10



Principe de fonctionnement

pfSense communique sur les réseaux LAN & WAN avec ses adresses IP virtuelles ; il n'utilise jamais l'adresse IP assignée à son interface.
En cas de défaillance de pfSenseA (pfSense primaire), pfSenseB (pfSense secondaire) prend le relais sans aucune interruption de service. La bascule de pfSenseA vers pfSenseB est totalement transparente.

Afin d'assurer la réplication du serveur pfSenseA vers le serveur pfSenseB, 3 éléments doivent être configurés : CARP, pfsync et XML-RPC.


CARP

CARP (Common Address Redundancy Protocol) est un protocole permettant à plusieurs hôtes présents sur un même réseau de partager une adresse IP.

Ici, nous utilisons CARP afin de partager une adresse IP WAN et une adresse IP LAN sur nos serveurs pfSense.
C'est cette adresse IP virtuelle que pfSense va utiliser pour sa communication sur le réseau. Ainsi, en cas de défaillance du pfSense primaire (pfSenseA), le pfSense secondaire (pfSenseB) prendra le relais de manière transparente au niveau réseau (reprise de l'adresse IP virtuelle).


pfsync

pfsync est un protocole permettant de synchroniser entre deux serveurs pfSense l'état des connexions en cours (et de manière plus large entre deux serveurs exécutant le firewall Packet Filter). Ainsi, en cas de défaillance du serveur primaire, l'état des connexions en cours est maintenu sur le serveur secondaire. Il n'y a donc pas de coupure liée à la bascule des services du pfSenseA vers le pfSenseB.

Il est recommandé d'effectuer cette synchronisation sur un lien dédié entre les deux serveurs pfSense. À défaut, le lien LAN peut être utilisé.
La réplication peut se faire d'un serveur primaire vers un ou plusieurs autres serveur(s).


XML-RPC

XML-RPC est un protocole permettant la réplication de données d'un serveur vers un autre. Il est utilisé dans pfSense afin de répliquer la configuration du serveur primaire vers le serveur secondaire.
Pour garantir son bon fonctionnement, il est important qu'il utilise la même interface que celle utilisée par le protocole pfsync.



1. Configurer les adresses IP virtuelles

Afin de fonctionner, chaque serveur pfSense doit disposer d'une adresse IP sur son interface, ainsi qu'une adresse IP virtuelle qui sera partagée entre les deux serveurs pfSense. De ce fait, nous utilisons 3 adresses IP par réseau.

Pour configurer l'adresse IP virtuelle, se rendre dans "Firewall" > "Virtual IPs" :



Cliquer sur l'icône "+ Add" pour ajouter une adresse IP virtuelle.
Les éléments à configurer sont les suivants :
  • Type : ici, nous avons quatre possibilités :
  1. IP Alias
  2. CARP
  3. Proxy ARP
  4. Other
Nous choisissons "CARP". Nous ne rentrons pas ici dans le détail de l'usage de chaque option. Pour plus d'informations, nous vous invitons à lire l'article What are Virtual IP Addresses - EN.
  • Interface : l'interface sur laquelle la VIP doit être configurée. Nous configurons la première sur l'interface WAN, puis la seconde sur l'interface LAN.
  • Address(es)  : l'adresse VIP et le masque du subnet de l'interface. Dans notre exemple : 172.25.46.100 et /24
  • Virtual IP Password : mot de passe permettant de sécuriser les échanges au sein du groupe d'hôtes se partageant la VIP. Ce mot de passe devra être re-saisi sur le pfSense secondaire.
  • VHID Group : Virtual Host Identifier. Un serveur peut faire parti de plusieurs groupes de VIP. Afin d'identifier chaque groupe, un ID unique lui est assigné. Nous laissons la valeur par défaut.
  • Advertising Frequency : la valeur du champ "Skew" à 0 désigne le master (pfSense primaire). Une valeur plus élevée désignera l'esclave (pfSense de secours). La valeur de "Base" correspond au timeout en seconde au bout duquel l'hôte sera considéré comme inaccessible. Nous recommandons de laisser la valeur par défaut : 1.

Exemple de résultat obtenu :



Nous procédons à la même configuration sur l'interface LAN.
Enfin, nous réalisons les mêmes configurations sur les interfaces WAN et LAN du serveur de secours (pfSenseB), en pensant bien à passer la valeur du champ "Skew" à 1.

Nous pouvons vérifier l'état de nos adresses IP virtuelles depuis le menu "Status"> "CARP (failover)" :




Dans le cas présent, les deux adresses VIP créées ont bien le statut "master" sur le pfSenseA :





2. Forcer l'utilisation des adresses IP virtuelles


Les adresses VIP sont déclarées, mais non-utilisées. Il reste à configurer pfSense pour qu'il utilise les adresses VIP plutôt que les adresses IP attribuées à ses interfaces logiques.
Pour cela, nous devons configurer pfSense pour qu'il utilise l'adresse VIP WAN sur le trafic sortant, l'adresse VIP LAN pour le trafic entrant et configurer les différents services pour qu'ils travaillent avec l'adresse VIP LAN comme adresse par défaut (pour les configuration OpenVPN ou DHCP, par exemple).


Configuration du NAT

Nous allons dans le menu Firewall > NAT. Dans l'onglet Outbound, nous cochons la case "Hybrid Outbound NAT rule generation. (Automatic Outbound NAT + rules below)".
Nous modifions les règles ou en ajoutons une afin que le trafic sortant utilise l'adresse VIP. Les champs à configurer sont les suivants :
  1. Disabled : cocher cette case pour désactiver la règle sans devoir la supprimer.
  2. Do not NAT : cocher cette case permet de désactiver le NAT pour le trafic correspondant à cette règle. Il est très rare de devoir cocher cette case.
  3. Interface : l'interface logique sur laquelle nous souhaitons définir notre règle de NAT. Dans notre cas, nous choisissons "WAN".
  4. Protocol : les protocoles concernés par cette règle de NAT. Nous choisissons "any"
  5. Source : le réseau source. Dans notre cas, il s'agit du réseau local, nous saisissons donc "192.168.0.0" et "/24" pour le masque.
  6. Destination : le réseau de destination. Dans notre cas, nous choisissons "any".
  7. Address : l'adresse à utiliser lors du NAT. Nous choisissons l'adresse VIP créée précédemment, soit "172.25.46.100 (VIP WAN)".
  8. Port : nous laissons ce champ vide.
  9. No XMLRPC Sync : cocher cette case pour ne pas copier la règle sur le pfSense secondaire. Nous laissons cette case non-cochée.
  10. Description : un champ informatif

Exemple de résultat obtenu :



Cette configuration n'est à faire que sur le pfSense primaire. La configuration sera dupliquée automatiquement sur le pfSense secondaire.


Configuration du service DHCP

Si pfSense fait office de serveur DHCP, nous allons dans le menu "Services" > "DHCP Server". Nous modifions le champ "Gateway" pour y préciser l'adresse VIP (192.168.0.10). Autrement, le serveur DHCP de pfSense va continuer à indiquer aux clients du service DHCP l'adresse IP de l'interface LAN du pfSense.
Nous pouvons également compléter le champ "Failover peer IP" en renseignant l'adresse IP de l'interface LAN du pfSense secondaire (192.168.0.12). Cette configuration optionnelle permet de partager les leases DHCP entre le pfSense primaire et le pfSense secondaire.
Attention, si ce champ est renseigner, il est nécessaire de modifier la valeur du "skew" du pfSense secondaire pour le passer à un nombre supérieur à 20.

Davantage d'informations sur la configuration du service DHCP : [pfSense] Configurer son serveur DHCP.


Configuration du service OpenVPN server

Si un serveur OpenVPN est configuré sur le pfSense, il est nécessaire de modifier l'interface d'écoute du service (normalement "WAN") pour la remplacer par l'adresse VIP (172.25.46.100).
Cette modification s'opère dans "VPN" > "Servers".

Davantage d'informations sur la configuration du service OpenVPN : [pfSense] Monter un accès OpenVPN site-à-site.


Configuration du service VPN IPsec

Si un tunnel IPsec est configuré sur le pfSense, il est nécessaire de modifier l'interface d'écoute du VPN IPsec (normalement "WAN") pour la remplacer par l'adresse VIP (172.25.46.100).
Cette modification s'opère dans "VPN" > "IPsec". La modification s'effectue sur la phase 1.



3. Configurer la haute-disponibilité

Il nous reste à configurer la haute-disponibilité. Pour cela, se rendre dans "System" > "High Avail. Sync" :



Depuis cette page, il y a 2 éléments à configurer : la partie pfsync (pour la synchronisation d'état) et XMLRPC Sync (pour la synchronisation de la configuration).


State Synchronization Settings (pfsync)

Les éléments à configurer sont les suivants :
  • Synchronize States : cocher cette case pour activer pfsync
  • Synchronize Interface : l'interface de synchronisation. Si nous disposons d'une interface dédiée à la synchronisation, nous la choisissons ; autrement, nous choisissons "LAN".
  • pfsync Synchronize Peer IP : saisir l'adresse IP du serveur pfSense de secours. Si pour le choix de l'interface (ci-dessus) nous avons choisi "LAN", nous indiquons l'adresse IP de l'interface LAN du pfSense secondaire ; si nous avons choisi une interface dédiée alors nous indiquons l'adresse IP de l'interface dédiée du pfSense secondaire. Par défaut, si aucune adresse IP n'est saisie, pfSense diffusera en multicast sur l'interface choisie préalablement.


Configuration Synchronization Settings (XMLRPC Sync)

  • Synchronize Config to IP : sur le serveur pfSense primaire, saisir l'adresse IP du serveur pfSense secondaire (comme précédemment, il faut saisir l'adresse IP de l'interface choisie). Ce doit être la même adresse IP que celle renseignée dans le champ "pfsync Synchronize Peer IP". Ce champ doit être laissé vide sur le serveur pfSense secondaire.
  • Remote System Username : sur le serveur pfSense primaire, saisir le nom d'utilisateur utilisé pour se connecter sur le WebGUI du pfSense de secours ("admin" par défaut). Ce champ doit être laissé vide sur le serveur pfSense de secours.
  • Remote System Password : sur le serveur pfSense primaire, saisir le mot de passe du compte utilisateur saisi ci-dessus. Ce champ doit être laissé vide sur le serveur pfSense de secours.

Puis, nous choisissons les services que nous souhaitons synchroniser en cochant les cases appropriées. Par défaut, nous recommandons de tout cocher (Toggle All).

Exemple de résultat obtenu :




Autoriser les flux de réplication au niveau des règles du firewall

Il nous reste à autoriser les flux de réplications sur les firewall. La configuration se passe dans "Firewall" > "Rules".
Si la réplication se fait via l'interface LAN, les règles de firewall sont à appliquer sur cette interface ; si nous utilisons une interface dédiée, les règles seront à appliquer sur celle-ci.

Il y a deux flux réseau à autoriser :
  • le flux pour la synchronisation XML-RPC qui s'effectue via le port 443
  • le flux pour la synchronisation du protocole pfsync

Sur le firewall primaire, nous créons donc une première règle de firewall (en cliquant sur le bouton "Add") avec les paramètres suivants :
  • Action : nous choisissons "Pass"
  • Interface : nous choisissons l'interface dédiée à la réplication si le pfSense en possède une. Autrement, nous choisissons "LAN"
  • Address Family : nous laissons "IPv4"
  • Protocol : nous choisissons "TCP"
  • Source : nous indiquons un alias qui contiendra les adresses IP des interfaces de synchronisation de chaque pfSense (dans notre cas, cet alias contiendra les adresses IP "192.168.0.11" et "192.168.0.12"). Si cette notion d'alias n'est pas claire pour vous, vous pouvez choisir l'ensemble du réseau rattaché à l'interface de synchronisation (dans notre cas, ce serait "LAN net")
  • Destination : nous choisissons "This firewall (self)"
  • Destination port range : choisir "HTTPS (443)"

Exemple de résultat obtenu :



Sur le firewall primaire toujours, nous créons une seconde règle de firewall avec les paramètres suivants :
  • Action : nous choisissons "Pass"
  • Interface : nous choisissons l'interface dédiée à la réplication si le pfSense en possède une. Autrement, nous choisissons "LAN"
  • Address Family : nous laissons "IPv4"
  • Protocol : nous choisissons "PFSYNC"
  • Source : nous indiquons un alias qui contiendra les adresses IP des interfaces de synchronisation de chaque pfSense (dans notre cas, cet alias contiendra les adresses IP "192.168.0.11" et "192.168.0.12"). Si cette notion d'alias n'est pas claire pour vous, vous pouvez choisir l'ensemble du réseau rattaché à l'interface de synchronisation (dans notre cas, ce serait "LAN net")
  • Destination : nous choisissons "This firewall (self)"

Exemple de résultat obtenu :



Ces deux règles de firewall ont été répliquées automatiquement sur le pfSense secondaire.



4. Vérifier le bon fonctionnement de la haute-disponibilité

L'ensemble doit, à ce stade, être opérationnel. Vérifions !


Vérifier le statut du CARP (adresse VIP)

Nous pouvons vérifier l'état de nos adresses IP virtuelles depuis le menu "Status"> "CARP (failover)" :



Les adresses VIP doivent avoir le statut "MASTER" sur le pfSense primaire et "BACKUP" sur le pfSense secondaire.


Vérifier la réplication

Nous pouvons naviguer dans le menu "Firewall" > "Rules" et "Firewall" > "NAT" et vérifier que les règles créées sur le pfSense primaire sont bien présentes également sur le pfSense secondaire.


Faire des tests !

Avant toute chose, à ce stade, il est important de faire une sauvegarde de vos serveurs pfSense ("Diagnostics" > "Backup & Restore").

Ensuite, pour tester le bon fonctionnement de la haute-disponibilité, plusieurs tests peuvent être réalisés. En voici quelques exemples :
  • arrêter le pfSense primaire
  • débrancher le câble réseau de l'interface LAN ou WAN du pfSense primaire
  • désactiver le service CARP sur le pfSense primaire ("Status" > "CARP (failover)")
  • télécharger un fichier ou lancer des requêtes ping lors de la bascule du primaire vers le secondaire



Pour aller plus loin

[pfSense] Comprendre la gestion des interfaces réseaux
[pfSense] Configurer son serveur DHCP
[pfSense] Mettre à jour son serveur pfSense
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Configurer un dual-WAN (plusieurs connexions Internet)


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Nouveau : découvrez nos firewall Gbps full-SSD pour pfSense 2.4+

       

store.provya.fr

icon Tags de l'article :

42 commentaires

xhark - 04/10/2016 à 19:08:36

Félicitations pour ce tuto très complet ! je crois que tu as omis l'IP en 172 du slave sur ton schéma ?

@répondre #lien

Guillaume - 13/10/2016 à 14:03:05

@xhark : Bonjour,
Merci pour ton sympathique commentaire.

Effectivement, j'avais oublié une adresse IP. C'est corrigé !

Guillaume
--
Provya

@répondre #lien

Orka - 20/12/2016 à 16:30:05

Bonjour,
merci pour ce guide très complet. j'aurais une question a propos des utilisateurs, est-il possible d'importer un fichier (csv, xml ou autre) comportant les login et mots de passe des nouveaux utilisateurs ?
Me trouvant dans un centre de formation les utilisateurs changent fréquemment!
Merci par avance de votre réponse

@répondre #lien

Guillaume - 28/12/2016 à 08:04:19

@Orka :
Bonjour,
Il n'est pas possible d'importer un fichier comportant la liste de vos utilisateurs.
Il est en revanche possible de connecter pfSense à un serveur LDAP ou RADIUS, si vous en avez un, pour l'authentification de vos utilisateurs.

Cordialement,

Guillaume
--
Provya

@répondre #lien

barifaga - 25/01/2017 à 13:46:21

magnifique tuto merci infiniment

@répondre #lien

Soso - 23/04/2017 à 02:22:42

Très bon tuto, il m'a beaucoup aidé. merci

@répondre #lien

Akeena64 - 23/08/2017 à 07:41:56

Très bon tuto, impec !!!! ;-) ....... merki

Une question :

dans le cas ou on a, non pas une IP mais deux au niveau Wan et 2 IP au niveau Lan, dans ce cas comment cela se passe ?

je m'explique : j'ai deux switch en amont et deux switch en aval (redondance). Ces switch sont rattachés via 4 liens (2 + 2) sur les deux pfsense : ce qui fait que j'ai deux IP coté Wan sur un pfsense x 2 et deux IP coté Lan sur un pfsense x 2 !

Merci pour votre réponse.
Akeena

@répondre #lien

akeena - 23/08/2017 à 07:43:56

me suis trompé, c'est (4 + 4) !

@répondre #lien

Guillaume - 25/08/2017 à 07:43:01

@Akeena64 :
Bonjour,
Merci pour votre commentaire.

Dans votre cas, si vos switch sont en stack, vous devez faire une interface LAGG sur votre pfSense (protocole LACP). Ainsi vous n'aurez qu'une seule interface logique WAN à configurer côté pfSense. Il faut bien-sûr configurer vos ports de switch en conséquence.
Si vos switch ne sont pas en stack, alors vous devez créer autant d'interfaces que nécessaire (2 WAN et 2 LAN dans votre cas) et configurer une adresse VIP sur chacune de ces interfaces. Mais je ne vois pas comment cette seconde méthode peut fonctionner correctement ; ce serait du bricolage.

Cordialement,

Guillaume
--
Provya

@répondre #lien

nla - 17/10/2017 à 10:42:25

bonjour,

merci pour ce tuto, juste une question est-ce que dans ce cas, j'ai besoin des switch configurable ou non, merci d'avances !


salutations.

@répondre #lien

Guillaume - 23/10/2017 à 14:33:49

@nla :
Bonjour,
Si par switch configurables, tu veux dire switch supportant les VLAN, la réponse est : non ce n'est pas nécessaire.

L'utilisation de ce type de switch est obligatoire uniquement si l'on souhaite mettre en place des VLANs

Cordialement,

Guillaume
--
Provya

@répondre #lien

PapaSan - 29/11/2017 à 11:03:58

Bonjour,

super tuto dont je vais surement m'inspirer pour mon POC.
Par contre, et j'ai du mal à trouver de la doc dessus, peut-on mettre en place une console centralisée du cluster? via une des IP virtuelle?

Merci pour ton retour

@répondre #lien

Guillaume - 30/11/2017 à 14:41:41

@PapaSan :
Bonjour,

Que veux-tu dire par console centralisée ?
Les configurations de bases doivent se faire sur les 2 pfSense ; par exemple : assigner les réseaux aux bonnes interfaces physiques.
Puis, en mode cluster, les configurations réalisées sur le pfSense primaire sont répliquées sur le pfSense secondaire. Idem pour la table d'état.

Cordialement,

Guillaume
--
Provya

@répondre #lien

chris cool - 12/12/2017 à 22:06:45

gg pour cette doc

oui y a pas de console uniquem
pareil sur stormshield ca push sur le second.

sous pfsense en revanche si on reboot le primaire on bascule sur le second mais si le primaire reboot on rebascule automatiquement de nouveau sur le primaire de memoire guillaume ?

@répondre #lien

Guillaume - 13/12/2017 à 11:06:28

@chris cool :
Bonjour,

En effet, lorsque le primaire repasse UP, il reprend automatiquement la main (il reprend sa place de master).

Cordialement,

Guillaume
--
Provya

@répondre #lien

matth_94 - 20/12/2017 à 17:10:21

Bonjour,

Votre tuto est vraiment très intéressent.

Si pendant que le master est down, des modifications sont apportées au secondaire, est-ce que celle-ci sont présente sur le primaire lorsque celui-ci reprends la main?

Merci d'avance.
Cordialement,
Matthieu

@répondre #lien

Guillaume - 20/12/2017 à 17:56:47

@matth_94 :
Bonjour,

Non. La synchronisation se fait uniquement du primaire vers le secondaire.

Au passage, je vois sur le site de votre société que vous indiquez intégrer du pfSense. Si je peux me permettre, il serait pertinent que vous vous montiez un lab de cluster pfSense (des VMs suffisent) pour faire ce type de tests avant d'en intégrer chez vos clients.

Cordialement,

Guillaume
--
Provya

@répondre #lien

matth_94 - 20/12/2017 à 19:06:31

@Guillaume :

Bonjour et merci pour votre réponse rapide.
Ma question venez après un test en poc et votre réponse confirme mes observations.

@répondre #lien

John - 29/12/2017 à 02:25:32

Bonjour Guillaume
Je souhaiterai monter un cluster de 3 PFSense redondants.
Quels sonts les points qui different du tuto, respectivement quels sonts les points important à configurer pour que tout fonctionne correctement ?
Merci d avance pour ta réponse.
John

@répondre #lien

John - 29/12/2017 à 19:33:20

Bonjour Guillaume

Quelle procédure conseilles-tu de suivre lorsque le PFSense primaire/Master d un cluster CARP est défaillant et doit etre remplacé par un nouveau Hardware ?

Peut-on simplement refaire une installation PFSense de base en configurant les memes ports que sur le PFSense défaillant, puis simplement le resynchroniser depuis le PFSense Backup (qui devrait maintenant etre Master) ?

Merci d avance pour ta réponse
John

@répondre #lien

Guillaume - 30/12/2017 à 10:07:23

@John :
Bonjour,

Pourquoi vouloir mettre en place un cluster de 3 pfSense ?

@John :
C'est possible de faire ainsi, en adaptant la configuration.
Vous pouvez également restaurer depuis une sauvegarde récente.

Cordialement,

Guillaume
--
Provya

@répondre #lien

Guillaume - 28/02/2018 à 00:58:54

Bonjour Guillaume,

Merci pour votre excellent Tuto.

Je dispose de 2 serveurs 1U avec 4 interfaces Gb chacun.
J'ai également une connexion internet redondée en VRRP coté WAN et deux switchs non stackés (avec jartière trunck) coté LAN.

Si j'interprète bien votre schéma, il est inutile de mettre un câble de hearthbeat directement entre mes deux serveurs?
Question subsidiaire: Dans ce cas est-il possible de configurer un agrégat de deux interfaces par serveur qui ne nécessite aucune configuration côté switch (mot de passe ena perdu) un peu à la mode Windows serveur 2012/2016 qui propose de faire un teaming loadbalancing sans config lacp ou etherchannel côté switch, avec juste des interfaces en mode access?

Cela me permettrait de mettre une interface de chaque agrégat sur chacun des deux switchs et d'avoir du ha à tous les niveaux.

Merci pour vos réponses.

Guillaume

@répondre #lien

Guillaume - 28/02/2018 à 18:22:52

@Guillaume :
Bonjour,

Il n'est pas indispensable de disposer d'une interface de synchronisation sur chaque serveur pfSense. Dans ce cas, la synchronisation se fera via l'interface LAN. Cependant, si vous disposez de suffisamment de ports réseaux sur vos serveurs pfSense, il est recommandé d'utiliser une interface dédiée.

Je ne connais pas le teaming load-balancing de Windows, mais, à ma connaissance, pfSense ne propose pas de solution équivalente au mode de fonctionnement que vous décrivez.
Au passage, le mieux serait de réinitialiser votre switch. C'est simple et rapide à faire. Autrement, votre switch est figé, sans possibilité d'évolutions de sa configuration. C'est dommage.

Cordialement,

Guillaume
--
Provya

@répondre #lien

OVYA - 21/05/2018 à 16:40:47

Bonjour Guillaume,

Bravo et merci pour ces excellents TUTO.

J'ai actuellement 1 Alix 2D13 avec pfSense en v.2.3.4 .

Coté WAN , une FTTH et une ADSL, configurées en DUAL WAN.

Je souhaite aujourd'hui mettre en place un second pfSense pour faire du Load Balancing et du FailOver. Il arrive régulièrement que le pfSense en place tombe ...

Peux-tu me dire si j'ai besoin d'avoir le meme modèle de ALIX , et de la meme version de pfSense pour la synchro et le bon fonctionnement en LB ?

Car aujourd'hui , impossible de trouver un Alix 2D13 encore dans le commerce ...

Merci

Val

@répondre #lien

Guillaume - 22/05/2018 à 08:11:35

@OVYA :
Bonjour,

Non, ce n'est pas nécessaire d'avoir le même modèle hardware sur les 2 pfSense en LB.
Dans le choix du hardware, faites attention à bien choisir un modèle disposant d'un processeur 64 bits (pré-requis à pfSense 2.4) et supportant les instructions AES-NI (pré-requis à pfSense 2.5).

pfSense 2.3.4 est vraiment une vieille version. Il faudrait penser à mettre à jour. Vous pouvez vous appuyer sur notre article pour mettre à jour pfSense : Mettre à jour son serveur pfSense.

Enfin, un pfSense qui tombe régulièrement, ce n'est pas du tout normal ; c'est qu'il y a un problème a corriger (peut-être hardware).

Cordialement,

Guillaume
--
Provya

@répondre #lien

OVYA - 22/05/2018 à 09:28:09

Bonjour Guillaume,

merci pour votre retour,

Je ne peux malheureusement pas mettre à jour mon pfSense, étant sur une archi i386 ...

Je suis plutôt bon pour changer de matériel !

Le CPU est souvent surchargé, le pfSense supportant le role de DNS , DHCP , VPN et Firewall .

Lorsque nous avons une dizaine de clients connectés en VPN , des RSYNC ( rSnapshot, Borg ) partant vers des serveurs OVH , et de nombreux clients allumant leur PC dans les locaux, le pfSense freeze souvent , et necessite un reboot complet ( électrique ) pour retrouver un état nominal.

Le seul contournement est de ne faire des Rsync que hors heures ouvrées.

Je vous remercie une nouvelle fois pour votre support.

Cordialement,

Val

@répondre #lien

Guillaume - 22/05/2018 à 16:17:25

@OVYA :

La dernière version de pfSense disponible pour les architectures i386 est la 2.3.5-RELEASE-p2.
Mais en fait je réalise que j'avais mal lu votre commentaire : je croyais que vous étiez en version 1.2 ... au temps pour moi :-)

Dernière précision importante : il est indispensable que les 2 pfSense en cluster soient dans la même version.

Cordialement,

Guillaume
--
Provya

@répondre #lien

OVYA - 22/05/2018 à 16:24:26

@Guillaume :

Je n'arrive pas à passer en 2.3.5. Je suis en 2.3.4, et le système d'update me dit que je suis à jour et qu'il n'y a rien d'autre de disponible ...

Quoi qu'il en soit , je vais changer de matériel. Peut-etre du Netgear. Auriez-vous un modèle à me conseiller pour faire un cluster ?

@répondre #lien

saf - 03/06/2018 à 11:38:29

le failover marche en tant que passerelle mais ne marche pas en tant que proxy

@répondre #lien

Guillaume - 06/06/2018 à 14:46:45

@saf :
Bonjour,

Je ne comprends pas votre commentaire.

Cordialement,

Guillaume
--
Provya

@répondre #lien

OVYA - 06/06/2018 à 14:55:18

Bonjour Guillaume,

Je souhaite acquérir le PRO-SOHO, cependant, vous n'avez que E-BAY comme plate-forme e-commerce ?

@répondre #lien

Guillaume - 07/06/2018 à 07:44:04

@OVYA :
Bonjour,

Pour le moment nous n'utilisons que e-bay de manière temporaire ; notre plateforme de e-commerce est en cours de finalisation.

EDIT : notre store est en ligne https://store.provya.fr

Si vous ne souhaitez pas passer par e-bay, vous pouvez m'envoyer un e-mail à contact@provya.fr et je vous transmettrai un bon de commande avec nos possibilités de paiement.

Cordialement,

Guillaume
--
Provya

@répondre #lien

OVYA - 08/06/2018 à 15:55:53

@Guillaume :

Ok je pense que nous allons procéder ainsi.

Question technique. Aujourd'hui, sur notre pfSense nous avons 8 comptes VPN actifs.

Est-ce qu'un Backup de notre pfSense actuel permettra, en restaurant le XML sur le futur matériel, de conserver la connexion de ces derniers sur notre infra ? ou faut-il tous les recréer ?

merci

@répondre #lien

Guillaume - 11/06/2018 à 18:57:28

@OVYA :
Bonjour,

Oui, bien-sûr. Les comptes VPN seront recréés par l'import XML.

Cordialement,

Guillaume
--
Provya

@répondre #lien

myassa - 25/06/2018 à 15:46:54

bonjour; je veux bien voir un article sur load balancing car jai eu un problème dans ce sujet je ne sais par quoi mettre dans le champs monitor pour ajouter un pool j’ai lu 2 tuto qui parle de load balancing l'un a mit ICMP (supinfo)voici le lien file:///F:/pf/Load%20balancing%20avec%20PfSense%20%20%20SUPINFO,%20%C3%89cole%20Sup%C3%A9rieure%20d'Informatique.htm et l'autre a mit HTTP (IT) et un autre probleme dans status/load balancer/pools dans la case server chez moi c'est affiché (00.00%)pas (100.00%)pour les 2 adresses aussi dans status/loadbalancer/virtual servers dans la case status chez c'est affiché Down pas Active je ne sais pas pourquoi svp je veux la repense plus vite possible je travail sur virtual box sur laquelle j’ai installé pfsense et Linux Ubuntu , merci d'avance .

@répondre #lien

Guillaume - 26/06/2018 à 11:17:05

@myassa :
Bonjour,

Nous n'avons pas d'articles sur le load-balancing et ce n'est, a priori, pas prévu que nous en fassions.

Vous pouvez chercher et poser vos questions sur le forum pfSense : https://forum.netgate.com/.

Cordialement,

Guillaume Houdé
--
Provya

@répondre #lien

OVYA - 03/10/2018 à 16:42:53

Bonjour Guillaume,

je viens de passer à la version 2.4.4 de Pfsense , et je remarque que de nouvelles options ont fait leurs apparitions , notamment sous SYSTEM/ROUTING/Gateways : Default gateway , qui propose " Automatic" , " Groupe Gateway " , "WAN " ou "OPT1 " .

Que faut-il sélectionner pour du FailOver Tier 1 WAN , Tier 2 OPT1 ?


Merci

@répondre #lien

Guillaume - 03/10/2018 à 17:29:06

@OVYA :
Bonjour,

A votre avis ?
Je suis sûr que vous avez la réponse ;-)

Cordialement,

Guillaume
--
Provya

@répondre #lien

OVYA - 10/10/2018 à 14:48:17

Je dirai WAN, mais Automatic peut aussi le faire. Quel est le best Practice ?

@répondre #lien

Michel - 13/11/2018 à 21:09:02

Bonjour,

Votre article est très intéressant.

Je me posais la question suivante :

Adaptons la modification suivante à la topologie présentée en haut de cet article :

pfsenseA est connecté à un WAN1 (source internet 1 type VDSL).

pfsenseB est connecté à un WAN2 (source internet 2 type satellite).

au lieu qu'ils soient tous les deux connectés au même WAN.

pfsense A et pfsense B sont bien entendu connectés sur le même LAN.

Est-ce réalisable ?

Le but recherché :

Disposer de deux serveurs pfsenses redondant, mais connectés à deux connexions internet différentes.

Je vous remercie d'avance.


Michel

@répondre #lien

Guillaume - 14/11/2018 à 09:40:33

@Michel :
Bonjour Michel,

Je ne vois pas l'intérêt d'une telle configuration. Autant connecter vos 2 pfSense à vos 2 connexions Internet. Ainsi vous êtes complètement redondant.
Il existe un article sur la configuration d'un dual-WAN : pfSense - Configurer un dual-WAN (plusieurs connexions Internet)

Si vous n'avez pas suffisamment de port réseau physique sur votre pfSense, alors vous pouvez recourir à des VLAN (en adoptant un switch suportant les VLAN, bien-sûr).
Article détaillant comment configurer ses VLAN sur pfSense : pfSense - Configurer ses VLAN

Cordialement,

Guillaume
--
Provya

@répondre #lien

icon Flux RSS des commentaires de cet article