Besoin de conseils PFSense en redondance
-
Coté WAN, il y a plusieurs aspects bien différents selon que tu veux couvrir une panne éventuelle de pfSense (c'est ce que couvre le cluster) ou un défaut de disponibilité de l'accès internet (c'est ce que couvrirait une double liaison internet au travers de 2 providers différents, via 2 chemins physiques différents si tu es vraiment paranoïaque ou que la criticité est vraiment importante.
Pour revenir au cas "cluster", l'adresse que voient les services qui accèdent depuis internet, c'est bien la VIP, qui passe d'un pfSense à l'autre, ce qui assure la haute disponibilité.
Je t'invite tout de même à faire un schéma précis y compris des points d'accès internet et des adresses IP mises en jeu.
Si tu déploies 2 boitiers pfSense derrière un seul "modem" ADSL, c'est faire la supposition qu'il y a plus de risque de panne ou d'arrêt avec ton boitier pfSense qu'avec le modem ADSL.Par ailleurs, si ce boitier ne fonctionne pas en mode bridge, c'est lui qui supporte l'adresse IP unique externe et qui fait le routage vers la VIP pfSense qui est elle dans la RFC1819.
IPSec et OpenVPN font partie du bundle standard, pas de soucis.
La haute dispo OpenVPN n'est pas nécessairement un problème.
Avec IPSec, ça peut être un peu plus tricky ;) -
coté WAN: si j'ai bien compris il faut minimum 2 IP publiques physiques assignées aux interfaces réseaux physiques des 2 PFSense, et la 3e qui est virtuelle
N'oubliez pas: dans le même sous réseau.
Mes certificats clients OpenVPN sur le maitre sont-ils répliqués vers l'esclave automatiquement ? ce point est primordial pour moi
Je ne comprend pas en quoi cela peut être primordial. Quelle est la raison ?
coté WAN: si j'ai bien compris il faut minimum 2 IP publiques physiques assignées aux interfaces réseaux physiques des 2 PFSense, et la 3e qui est virtuelle
Ce qui est vrai pour Wan l'est pour toutes les interfaces de Pfsense si vous voulez que le cluster couvre la potentielle défaillance d'un de ces éléments.
-
salut salut
Pour vous éclaircir un peu le concept du HA avec pfsense
- I - Un cluster simple pfsense ==> 1 wan 1 lan 1 lien de synchro
si le pf maitre lache l'esclave prend le relais
- II - Un cluster à double wan ==> 2 wan 1 lan 1 lien de synchroEn situation normal
En situation de défaillance
-
A - Sur la zone extérieur au Pf
le wan 1 ou 2 est off mais la possibilité de sortir ou de rentrer dans votre réseau est là ==> Ha sur lien FAI ou rocade.
-
B - Sur les pf même
que le maitre ou l'esclave tombe le service est assuré
avec 1 wan
avec 2 wan
Les VIP
Elle sont activées par l'usage du concept CARP
1 vip par segment
C'est elle par la synchronisation qui font faire la bascule du services d'un pf à l'autre.Donc si vous avez deux FAI et un lan ==> 3 vip ==> 3 carp
Si comme moi vous avez une dmz ==> 4 vip ==> 4 carp
Apres le paramétrage de la bascule entre les lien FAI depuis le lan c'est un peu velu mais un y est pas encore.
Cordialement
-
-
Et après cela on en trouve toujours pour râler contre ce forum qui ne serait pas assez à l'écoute …
-
j'ai fait une bétise ? :'(
-
Pas du tout. Notre visiteur a été abondamment et judicieusement informé.
-
Merci infiniment à vous tous d'avoir pris le temps :), avec les schémas je comprends beaucoup mieux à présent
Pour revenir dans le contexte, j'ai un IPCop qui fonctionne d'une manière parfaitement stable depuis 9 ans, donc je m'en occupe plus et de ce fait je suis moins au courant de ce qui se fait actuellement
J'ai fait des recherches sur le net et j'ai pu me rendre compte que PFSense est "la" distribution en vogue, mais il reste encore des points à éclaircir pour moi, avant de me lancer dans le projet et investir au niveau matériel
Voici mon plan de réseau actuel (j'ai mis des IP fictives)
Le problème: nous avons une petite équipe et je suis le seul à "connaitre" les rudiments de Linux, sécurité et réseaux. Quand je suis absent pour une long période, je suis assez fébrile d’où l'idée d'un système en redondance. Peut-être que mon idée d'avoir 2 PFSense + 2 FAI est trop ambitieuse ? Techniquement je me sens capable de gérer un tel système, mais c'est pas le cas de mes collègues
Actuellement j'ai un IPCop de production et un autre de secours dans un placard, qui est tout configuré sauf les certificats clients VPN. Le problème sur IPCop il n'existe pas de système de sauvegarde de certificats OpenVPN clients afin de les transférer sur celui en secours en cas de basculement
Savez-vous si PFSense offre une telle possibilité ? ou la seule solution c'est le CARP ?PS: à l'époque j'ai fréquenté le forum IXUS pour ceux qui connaissent il y avait une rubrique IPCop avec un certain membre Franck très actif et compétent, toujours prêt à partager. Je retrouve ici encore plus de monde et quelque part c'est rassurant de se lancer dans l'aventure PFSense. Merci à vous ! ;)
-
PS: à l'époque j'ai fréquenté le forum IXUS pour ceux qui connaissent il y avait une rubrique IPCop avec un certain membre Franck très actif et compétent, toujours prêt à partager.
;D ;D alors ici tu ne vas pas être dépaysé ;D ;D
Si je lis bien ton schéma, tu as en réalité 2 LAN distincts, avec 2 IP WAN différentes, 2 fW, et donc le la nécessité de dupliquer la solution que tu vas retenir en terme de haute disponibilité ?
-
Salut salut
Pour la gestion des vpn avec l'add on openvpn je ne pourrais répondre, ni d'ailleurs pour ipsec.
Tout bonnement pour la raison que je ne les ai pas mis en place et ne me suis pas encore penché sur le sujet.Openvpn <=== correction
OpenVpn est un add on
Ce que j'ai pu constater tout de même, c'est que les add on ne se synchronisent pasCorrection ==> autant pour moi, openvpn est intégré à pfsense par défaut. <=== correction
Ipsec
Ipsec est intégré par défaut à pfsense donc on peut penser que la synchronisation se fait.Pour votre cas un double cluster, entendez par là un par site avec un un tunel ipsec entre les deux sites.
rajouter un deuxième FAI est une solution mais surcout est il justifié :
– pour le site principal ?
-- pour le site secondaire ?
-- pour les deux ?Aux vus de votre architecture avec les services annoncés :
- je pense que pour le principal oui c'est envisageable
- je pense que pour le secondaire c'est du superflux sauf si vous avez un besoin de ne pas perdre l'accès au services depuis celui-ci.
Dans tous les cas de figure si la boucle local vous lache à la sortie de votre réseau principal ou secondaire le services sera indisponible.
Cordialement.
-
;D ;D alors ici tu ne vas pas être dépaysé ;D ;D
Si je lis bien ton schéma, tu as en réalité 2 LAN distincts, avec 2 IP WAN différentes, 2 fW, et donc le la nécessité de dupliquer la solution que tu vas retenir en terme de haute disponibilité ?
Oui, c'est bien cela, sauf que la haute disponibilité du site secondaire n'est pas un problème pour moi. Sur ce site distant (à 600km) j'ai paramétré IPCop (1 production et 1 en secours) avec un simple tunnel IPSec permanent avec mon site principal, c'est tout.
J'ai pu testé le basculement en réel il y a 6 mois suite à un contrôle d'un électricien qui s'amuse à faire ON/OFF avec le disjonteur (sans protection onduleur sur ce site), le magasinier sur place a mis celui de secours et ça repart.
Le tunnel IPSec est nécessaire sur ce site pour des raisons applicatives
PS: il me semblait que Franck était le principal contributeur francophone d'IPCop, d'ou sa maitrise parfaite du produit. Depuis la disparition du forum d'IXUS, je sais plus ce qu'il est devenu
Salut salut
Pour la gestion des vpn avec l'add on openvpn je ne pourrais répondre, ni d'ailleurs pour ipsec.
Tout bonnement pour la raison que je ne les ai pas mis en place et ne me suis pas encore penché sur le sujet.Openvpn <=== correction
OpenVpn est un add on
Ce que j'ai pu constater tout de même, c'est que les add on ne se synchronisent pasCorrection ==> autant pour moi, openvpn est intégré à pfsense par défaut. <=== correction
Ipsec
Ipsec est intégré par défaut à pfsense donc on peut penser que la synchronisation se fait.Pour votre cas un double cluster, entendez par là un par site avec un un tunel ipsec entre les deux sites.
rajouter un deuxième FAI est une solution mais surcout est il justifié :
– pour le site principal ?
-- pour le site secondaire ?
-- pour les deux ?Aux vus de votre architecture avec les services annoncés :
- je pense que pour le principal oui c'est envisageable
- je pense que pour le secondaire c'est du superflux sauf si vous avez un besoin de ne pas perdre l'accès au services depuis celui-ci.
Dans tous les cas de figure si la boucle local vous lache à la sortie de votre réseau principal ou secondaire le services sera indisponible.
Cordialement.
Au vu de tous ces éléments je pense envisager la config suivante, corrigez moi si je me trompe:
-
Sur site principal: 2 PFSense en cluster, un seul FAI
-
Sur site secondaire: 2 PFSense (1 production, 1 en secours) avec un tunnel IPSec permanent. (Ou garder les 2 IPCop actuels dans le cas ou on peut établir un tunnel IPSec avec PFSense)
Il me reste juste une question en suspens: aujourd'hui j'ai qu'une seule adresse IP publique fournie par mon FAI qui est 212.222.223.217 (en statique sur la patte WAN d'IPCop), qui correspond à un nom d'hote mailhost.maboite.fr rendu nécessaire par le serveur de mail.
Si j'ai bien retenu la remarque de ccnet, j'ai besoin de 3 IP publiques et ces IP doivent-être dans le même sous réseau
Concrètement, comment je dois procéder auprès de mon FAI ? il faut que je leur demande encore 2 IP qui sont par exemple 212.222.223.218 et 212.222.223.219 ?
Merci encore à tous !
-
il faut que je leur demande encore 2 IP qui sont par exemple 212.222.223.218 et 212.222.223.219 ?
Probablement pas. Dans votre exemple ce serait un /29 donc 212.222.223.216/29 avec .223 en gateway. Le /30 est trop petit. Rappelez vous : dans le même sous réseau !
-
Mes besoins restent très basiques du coup je cherche pas forcément la nouveauté mais plutôt un produit stable et éprouvé
Ce qui me semble important, c'est de bien mesurer le niveau de service dont tu as besoin et de choisir la solution en conséquence.
pfSense est clairement, jusqu'en 2.2.6, une solution stable et éprouvée.pour la 2.3, je epsne qu'il faut attendre encore un peu que ce soit stabilisé et ne pas se précipiter ;)
Vient ensuite l'aspect haute disponibilité.
Si le bénéfice d'un cluster avec CARP est indéniable en terme de niveau de service dans le cas où tu soupçonnes ou veux te préserver d'un risque de panne au niveau du pare-feu, comme on l'a déjà évoqué, ça ne couvre que le pare-feu et pas un défaut au niveau de l'ISP, et c'est au prix d'une complexité supplémentaire qu'il ne faut pas négliger.
De mon expérience personnelle, je rencontre plus d'interruptions de service potentielles liées à des défaut de ligne (ISP) que de pannes ou arrêt sur les FW sur les plate-formes que j'ai déployé.
Donc, de mon point de vue, si l'objectif est le taux de disponibilité de l'ensemble de la solution, il faut d'abord regarder les aspects "dual ISP".
En ce qui concerne OpenVPN, pour bénéficier d'un service qui écoute sur plusieurs interfaces sans avoir à dupliquer les configurations, il suffit de configurer ton serveur OpenVPN à l'écoute sur localhost (127.0.0.1) et à faire un forward, depuis tes interfaces WAN, vers localhost pour le port que tu as défini dans ta conf client.
Dans le cas du déploiement d'un cluster (CARP) avec un seul ISP, la solution la plus simple (mais pas nécessairement la plus adaptée en fonction de tes besoins), c'est d'avoir un modem/routeur xDSL en mode routeur, configuré pour tout rediriger vers la VIP WAN de tes pfSense, laquelle peut-être en RFC1819.
-
c'est au prix d'une complexité supplémentaire qu'il ne faut pas négliger.
De mon expérience personnelle, je rencontre plus d'interruptions de service potentielles liées à des défaut de ligne (ISP) que de pannes ou arrêt sur les FW sur les plate-formes que j'ai déployé.
justement je cogite depuis hier soir sur ce point précis, mon IPCop tourne depuis 9 ans sans aucun bug et réellement 0 maintenance, même pas besoin de le redémarrer, ça m'arrive de le redémarrer une fois par an l'histoire de vider "le cache", c'est tout
chez nous on a pas de problème de défaut de ligne, donc c'est pas vraiment une priorité
pour revenir à mon problème à la source, en résumé: j'aimerais pouvoir basculer en cas de panne sur le firewall de secours, et sans avoir à régénérer tous les certificats OpenVPN pour les clients (j'en ai environ 50)
j'ai vu que PFSense sait gérer du VPN PPTP, même si c'est moins "secure" que OpenVPN ça peut-être une solution pour moi pour ne plus à s'occuper des certificats clients ? d'autant plus que j'ai déjà déployé un serveur RADIUS sur le LAN pour le WIFI
-
Salut salut salut
je vais émettre une simple suggestion, qui doit ne rester que cela.
- si vous avez 2 pc en spare avec la possibilité de monter le cluster avec un total de 3 cartes une par segment (1 lan 1 wan 1 synchro)
- pour faire le test pas vraiment primordial d'avoir les cluster en direct sur la box , mais un sous réseau pour protéger un nouveau service tres sensible par exemble.
- y rajouter le services de vpn que vous voulez tester ainsi qu'un pc client derrière.
- ensuite faire les tests suivant
–- j'enleve le cable réseau sur la sone wan(externe du pf maitre) et regarde ce qu il se passe du coté pf esclave et coté vpn
--- je remet le cable en place sur le pf maitre
--- j'arrete le pf maitre
--- je remet en route le pf maitre
Je deconseile de le virtualiser car nous n'aurez pas forcement un visu sur le comportement du cluster.
Personnellement, je virtualise ce type de produit pour tester les versions avant une mise en prod sur des machines ayant déjà le produit, pour ne pas perturber les utilisateurs -
Merci Tatave pour votre suggestion, il faut y aller pas le choix :D
je vais monter un petit "laboratoire de test" pour voir ce que ça donne
-
Salut salut
Fait ton test et tiens nous au courant
-
pour revenir à mon problème à la source, en résumé: j'aimerais pouvoir basculer en cas de panne sur le firewall de secours, et sans avoir à régénérer tous les certificats OpenVPN pour les clients (j'en ai environ 50)
A mon avis, il y a dans la description de l'ébauche de solution quelque chose de biaisé :
Techniquement, il n'est pas nécessaire, pour que OpenVPN fonctionne, de dupliquer tous les certificats depuis le serveur initial vers le serveur de remplacement.
Seuls les certificats des services sont nécessaires. Les certificats clients sont installés…. coté client.Ce qui peut être souhaitable bien sûr, c'est de disposer d'une sauvegarde de ces certificats clients à titre de back-up mais cela n'a rien à voir avec les aspects "fail-over".
La sauvegarde de la configuration de pfSense génère un fichier XML qui, accessoirement ;) contient ces certificats (serveurs et clients). Mon point au dessus est là juste pour expliquer ce qui est, techniquement, important.
Du coup, avoir une machine de remplacement sur laquelle on a déjà restauré la configuration ou sur laquelle on restaure, au moment ou on en a besoin, la dernière configuration sauvegardée va répondre à ton besoin si le temps nécessaire au switch est acceptable.
-
Salut salut
Si l'on veut que cela soit transparent pour les utilisateurs, je dirais non. Pas de machine en spare qui n'est pas une copie stricte de la prod et à jour (os/certificats/plugin..)
Le HA est le plus pratique pour la transparence utilisateur, pas pour la partie administration / assistance / gestion réseau que l'on soit bien d'accord avec cela.
Autre réflexion, absence de l'admin ou disparition de ce dernier sans laisser de trace au moment où la machine non pf non HA lâche que faire ?
==> coupure de prod
==> perte d'exploitation
==> mécontentement des utilisateurs (passe encore, quoi que) mais de la direction qui cela fait plus mal pour le retour de baton.
==> retarde de livraison et ou pénalité.
=============> bref, je n'aimerais pas être celui qui dit ok on reste comme çà et puis on vera le jour où cela arriveraJe nuance au dela de l'aspect technique:
En fonction des budgets et des impératifs financier qui sont à prendre en compte quand on est à 1 euro près , mais sur une architecture comme sité multi site et multi client (fixe/mobile)- Les budgets de fonctionnement qu'il faudrait prévoir et optimiser. (si 1 ou 2 fai, consommation électrique, entretien défaillance…
- Les budgets de l'acquisition de bon matériel du départ sans partir dans les excès minimalistes ou de grandeur.
- Prendre en compte l'accroissement des besoins en ressources sur le couts, moyens, et long terme en fonction des postes/services
- Les budgets homme/jours en cas de coupure de services et les limites, la marge...
-
pour revenir à mon problème à la source, en résumé: j'aimerais pouvoir basculer en cas de panne sur le firewall de secours, et sans avoir à régénérer tous les certificats OpenVPN pour les clients (j'en ai environ 50)
A mon avis, il y a dans la description de l'ébauche de solution quelque chose de biaisé :
Techniquement, il n'est pas nécessaire, pour que OpenVPN fonctionne, de dupliquer tous les certificats depuis le serveur initial vers le serveur de remplacement.
Seuls les certificats des services sont nécessaires. Les certificats clients sont installés…. coté client.Ce qui peut être souhaitable bien sûr, c'est de disposer d'une sauvegarde de ces certificats clients à titre de back-up mais cela n'a rien à voir avec les aspects "fail-over".
A deux reprises j'ai tenté d'attirer l'attention de notre visiteur sur ce point. Il ne m'a jamais répondu. La question était pourquoi la copie des certificats ? J'imagine qu'il pense que ces copies sont indispensables au fonctionnement d'Openvpn.
Ne connaissant pas véritablement le fonctionnement des certificats, il est du coup à utiliser une solution non pas "moins secure" (nous n'aurions pas le bon mot en français ?) mais une solution complètement douteuse (PPTP) et à proscrire. PPTP disparait de la version 2.3. Raison de plus pour ne pas foncer dans une impasse.
Que de contradictions par manque de connaissance oui, mais surtout encore une fois faute d'avoir boen posé les besoins fonctionnels: bien mesurer le niveau de service comme il a été dit.
Inutile de gloser sur la fiabilité de Pfsense, elle est acquise pour les version 2.2.x.
Le risque de défaillance avec le FAI est au moins égal, si ce n'est plus fort, que celui du firewall, si il est bien choisi et bien mis en œuvre en ce qui concerne le matériel. -
Si l'on veut que cela soit transparent pour les utilisateurs, je dirais non. Pas de machine en spare qui n'est pas une copie stricte de la prod et à jour (os/certificats/plugin..)
Nous sommes d'accord :)
Un cluster rend le passage d'une machine à l'autre pratiquement transparent. Ce n'est pas le cas d'un remplacement de machine.Mon propos était juste de réagir au point de dgtehc qui dit "aujourd’hui j'ai une machine en spare et ça me va bien"
Avec pfSense et un back-up, tu fais exactement la même chose et, à condition que ta machine de spare soit raisonnablement identique, ça marche très bien.Le cluster bien maitrisé, c'est le top ;D mais il y a quand même une petite complexité supplémentaire, prix de la transparence.
