[RESOLU] 2 pfSense en HA et accès OpenVPN d'un serveur à l'autre

Shadow aok

Bonjour,

J'ai 2 pfSense 2.2.6 en 172.16.7.1 et 172.16.7.2, synchronisés avec pfSync.
Je rentre via le WAN et OpenVPN sur 172.16.7.1 (mon client OpenVPN à une ip sur 172.31.0.0/24).

Il s'agit d'un vrack chez OVH, donc toutes les machines sont sur une sorte de même réseau local.
Chaque pfSense se trouve sur un hyperviseur avec ses autres VM.

Je peux pinger toutes les machines qui sont derrière 172.16.7.1 (sur le même hyperviseur) mais pas celles derrière 172.16.7.2.
Par contre, si je me connecte directement sur le pfSense 172.16.7.1 (idem avec l'autre), je ping bien toutes les machines, peu importe leur emplacement.

Je pensais à un soucis de firewall, mais je ne vois même pas le ping dans les logs de pfSense.
J'ai tout de même ajouté une règle LAN pour 172.31.0/24 sur les 2 pfSense, sans succès.

Quand mon client distant, connecté au VPN de 172.16.7.1, essaye de faire un traceroute vers 172.16.7.2 :

# traceroute 172.16.7.2
traceroute to 172.16.7.2 (172.16.7.2), 30 hops max, 60 byte packets
 1  172.31.0.1 (172.31.0.1)  19.167 ms  19.049 ms  19.015 ms
 2  * * *

Pourtant, dans OpenVPN, le réseau local est bien défini sur 172.16.7.0/24 et il existe bien une règle d'autorisation globale dans le firewall sur cette interface.

Avec une machine derrière le même pfSense que celui sur lequel je suis connecté en VPN :

# traceroute 172.16.7.2
traceroute to 172.16.7.2 (172.16.7.2), 30 hops max, 60 byte packets
 1  172.31.0.1 (172.31.0.1)  19.217 ms  19.128 ms  19.096 ms
 2  172.16.7.2 (172.16.7.2)  19.072 ms  20.327 ms  20.338 ms

Merci.

chris4916

Je ne comprends absolument rien à ton design. :'( :'( :'( ni le but d'un tel montage.

Si il s'agit d'une paire de FW en cluster avec CARP (est-ce ce que tu veux dire par synchronisés avec pfSense), alors je ne vois pas où sont les VIP.

Si tes deux pfSense partagent le même LAN, si tu accèdes au travers de celle qui n'est pas la route par défaut, la réponse va venir par la route par défaut et donc ça ne va par marcher :( sauf si la route par défaut est justement la VIP du LAN, ce qui se fait habituellement lorsqu'on met en place un cluster comme celui-ci.

Ou alors je n'ai vraiment rien compris à la question, ce qui est très possible ;D ;D ;D ;D

Tatave

salut salut

Pourriez vous nous mettre un schéma de votre montage avec des légendes pour le sens des flux (ou services / fonction ) ? Et le cas échéant se qui passent ou pas.

Etes vous sur que le FO Pfsense soit bien opérationnel sur le basculement ?

si j'ai bien suivi vous avez virtualiser Pfsense sur chez ovh.
Quel est votre niveau coté expertise de la virtualisation ?

Avez vous les moyens de faire une maquette physique si votre montage virtuel soit bancale (sens des flux , param …) pour mieux se rendre compte de vos erreurs ou manque sur la maitrise de ce projet ?

avez vous fait un test qu'avec un Pfsense sans le mode cluster ? pour valider avant mise en cluster que le montage était bon ?
Cordialement.

Shadow aok

Je vous fais ça mais j'ai bien une VIP en 172.16.7.254 que je n'ai pas définie comme route par défaut des autres VM derrière le pfsense, d'où peut-être le problème.
Les pfsense sont synchronisés avec carp en effet.

EDIT : Voici le schéma.

Donc, comme la route par défaut des VM d'un hyperviseur, est l'ip locale du pfsense de ce même hyperviseur, ça doit poser problème pour le VPN.
Le soucis, niveau contraintes, c'est que les utilisateurs doivent sortir par le même hyperviseur que celui où ils sont rentrés, et que si un pfsense tombe, on considère tout l'hyperviseur comme down (c'est répliqué de façon à ce qu'un seul hyperviseur puisse tout faire tourner sans problème).
Donc je ne peux pas avoir un pfsense comme passerelle principale de toute l'architecture.

Donc en gros, quand je suis connecté en VPN, mon ping vers une des VM doit passer par le pfsense sur lequel je suis connecté, et revenir.
J'ai testé en utilisant un subnet différent pour le second VPN, à savoir 172.32.0.0/24, mais ça n'aide pas.

Je n'ai pas fait de test avec un seul pfsense, mais cela ne me permettrait pas de reproduire le problème, vu que chaque VM a le pfsense de son hyperviseur comme passerelle, donc l'hyperviseur sur lequel je coup le pfsense serait out.

![Bjo anonyme.png](/public/imported_attachments/1/Bjo anonyme.png)
![Bjo anonyme.png_thumb](/public/imported_attachments/1/Bjo anonyme.png_thumb)

chris4916

Je commence à comprendre un peu mieux…. mais à peine et je pense que ce que tu veux faire, ça ne marche pas, ou alors j'ai regardé trop vite pour comprendre la subtilité.

pour moi, ton montage n'est pas un cluster pfSense. :-X

Pourquoi ? parce que un cluster pfSense, c'est (idéalement) 8 IP !

pour chaque serveur pfSense, il y a:

une IP WAN
une IP LAN
une IP de heartbeat

Soit 3 IP par serveur, et comme il y a 2 serveur, ça fait déjà 6 IP.
A ça tu rajoutes la VIP WAN et la VIP LAN qui sont les seules que les services devraient accéder.

Tu peux faire l'économie (radine) des 2 IP de heartbeat en t'appuyant sur les IP LAN par exemple mais c'est tout.

A partir de là, il n'y a basiquement qu'un seul serveur pfSense actif, l'autre n'est pas accédé car la VIP n'y est pas associée.

Shadow aok

Oui voilà, sauf que j'essaye d'avoir les 2 pfsense actifs en parallèle, sans maître ni esclave.
Donc la solution, vu que tout marche sauf le VPN, serait d'avoir 2 VPN non identiques, chacun sur une plage propre, et de faire 2 connexions au lieu d'une, pour joindre toutes les VM.

Enfin, ça ne résoudrait même pas le problème vu que toutes les VM sont sur le même sous-réseau :(

chris4916

Et en regardant bien ton schéma, il 'y a pas de cluster du tout d'ailleurs.
Si je le décris d'une manière différente, il s'agit de 2 LAN distincts, chacun derrière son propre pfSense.
Le problème, c'est que, Vrack aidant, les 2 LAN qui sont derrière ces serveurs pfSense sont en fait un seul LAN :o avec 2 gateways différentes ::)

Bref, pour moi, ça ne marche pas :-[

Shadow aok

Ouaip, ça ne peut pas marcher à cause de ces 2 gateways.
Je dois donc séparer les 2 réseaux.
Certaines VM pourront continuer à communiquer entre elles via des VLAN sur une seconde interface, de façon à ne pas passer par les passerelles.

chris4916

@Shadow:

Oui voilà, sauf que j'essaye d'avoir les 2 pfsense actifs en parallèle, sans maître ni esclave.

mais dans quel but exactement ?
pour de la haute dispo => il faut un cluster
pour du load balancing => ce n'est pas pfSense qui fait ça mais au mieux un reverse proxy ou un truc de ce genre.

Shadow aok

Le load-balacing qui est géré dans un premier temps par l'IP LB devant les 2 pfsense et ensuite par HAProxy sur les pfsense.

chris4916

@Shadow:

Le load-balacing qui est géré dans un premier temps par l'IP LB devant les 2 pfsense et ensuite par HAProxy sur les pfsense.

C'est là que l'idée est une fausse bonne idée, à mon avis 8)
Empiler 2 niveaux différents de load-balancing si au final tu accèdes derrière les mêmes machines… bof.

Un seul niveau suffit largement, derrière un cluster de pfSense si tu veux un FW (mais un seul est actif).

Tu peux éventuellement utiliser le HA proxy de pfSense, même si fonctionnellement, ce n'est pas la meilleure idée, mais à un instant donné, il n'y a qu'un seul HA proxy actif.

Shadow aok

Je suis obligé, car les ip lb d'OVH ne permettent de faire du LB que sur quelques ports.
Et j'ai besoin d'un LB interne, c'est là que sert vraiment le HAPRoxy.

jdh

Et qu'est ce qui vous pensez que pfSense pourrait fonctionner en Actif/Actif ?

Normalement on prépare son truc. Et on commence par lire la doc d'un outil.
Et là qu'est ce qu'elle dit la doc ?

chris4916

@Shadow:

Je suis obligé, car les ip lb d'OVH ne permettent de faire du LB que sur quelques ports.
Et j'ai besoin d'un LB interne, c'est là que sert vraiment le HAPRoxy.

La vraie question est de savoir si tu as besoin ou pas d'un cluster pfSense.
Si oui, tu en fais un sur la base de ce que j'ai décrit.

Ensuite, de ce pfSense, du t'appuies sur un load balancer (HA proxy) qui peut être celui de pfSense.

Je ne vois pas le problème :)

pas le load-balancing OVH mais uniquement HAproxy.

Shadow aok

Je vois bien et je vais changer ce qu'il faut.
J'ai essayé quelque chose d'impossible, tant pis, je passe à une configuration plus standard.

ccnet

Oui voilà, sauf que j'essaye d'avoir les 2 pfsense actifs en parallèle, sans maître ni esclave.

Ce n'est pas le design retenu pour Pfsense dans le cadre d'une solution haute disponibilité. Vous essayez de faire fonctionner un logiciel d'une façon pour laquelle il n'a pas été conçu. A partir de là …

Shadow aok

Je ne fais pas du HA avec pfsense, et ils ne sont pas en cluster en effet, il y a juste une synchro partielle via carp.
En gros, chaque hyperviseur a son pfsense, qui sert de passerelle WAN aux autres VM du même hyperviseur, mais peut tomber intégralement sans souci.

Le HA se fait autrement, et pas via les pfsense, chaque hyperviseur ayant les mêmes applicatifs hébergés.

Sinon, j'ai résolu mon souci en gardant l'ensemble du réseau local sur le même subnet.
J'ai simplement mis les 2 VPN sur des sous-réseaux distincts, 172.31.0.0/24 et 172.32.0.0/24, puis j'ai une route sur chaque pfsense pour leur faire connaître le sous-réseau utilisé par le pfsense de l'autre VPN et l'y renvoyer.

Au final, la seule chose qui ne marchait pas correctement, et n'avait pas accès à l'ensemble du réseau local, fonctionne désormais.
Donc oui, j'ai 2 pfsense actifs, et en partie synchronisés (pour ce qui peut et doit l'être, mais c'est normal, ils ne s'occupent pas de la HA.

Désolé si mon explication de base n'est pas claire.

chris4916

@Shadow:

Je ne fais pas du HA avec pfsense, et ils ne sont pas en cluster en effet, il y a juste une synchro partielle via carp.
…/...
Désolé si mon explication de base n'est pas claire.

L'essentiel étant probablement que ça fonctionne ;)

Il s'agit d'un problème de vocabulaire.
CARP (qui est l'acronyme de Common Address Redundancy Protocol), vise à gérer des IP virtuelles flottantes. Ce n'est pas de la synchro ;)
Si tu fais de la synchro de certains paramètres mais que tu n'implémentes pas de cluster, tu n’utilises pas CARP.
Comme ton message initial faisait référence à cette solution, je pensais qu'il y avait de IP flottantes mais… non.
C'est juste 2 FW sur le même LAN :-\