RESOLU - PB avec un nouveau tunnel OpenVPN (site à site)

jdh

Bravo pour l'utilisation du formulaire : il y a de l'info, la trace de votre démarche, des log, … Continuez !

Il y a des choses pas claires :

Concentrateur ?
'1 concentrateur OpenVPN en pfSense en 2.2.6 (ne fait que çà, le firewall est une autre machine'
Devons comprendre qu'il y a, sur le site central, :
Internet <-> Firewall (DMZ) <-> pfSense <->
Le firewall n'est pas un pfSense lui-même ?
nouvelle interface WAN ?
Si le schéma est : le concentrateur Vpn est un pfSense en DMZ du firewall; alors le nouveau WAN est une interface du firewall ?

Concernant le dernier point :
Si un firewall dispose de 2 interfaces WAN, Il n'y a normalement rien à faire de spécial si le flux est entrant sur une ip de WAN2.

nc21

Merci de votre aide.
Je vois que je n'ai pas été assez clair, pas si facile en fait….

donc:
concentrateur VPN : pour dire que ce cluster pfSense ne fait que concentrer tous les tunnels Open VPN, il y a un autre firewall qui n'est pas sous pfSense (Juniper) projet de remplacement d'ici la fin de l'année.
au siège : Internet <-> Firewall Juniper <-> en DMZ cluster pfSense OpenVPN <->

La nouvelle interface WAN c'est sur le firewall du site distant (pas au siège)
1 WAN existant avec une SDSL toute pourri
1 nouveau WAN avec une liaison Fibre derrière

Le but étant de faire sortir la connexion VPN depuis le site distant par ce nouveau WAN (çà c'est bon)
au siège le noeud maitre du cluster pf reçoit bien sur çà VIP (CARP) les paquets UDP en provenance de la bonne IP publique du site distant, mais rien n'a l'aire de ressortir.

Comme je connais pas bien les tunnels OpenVPN, je connais mieux l'IPSEC, je ne sais pas ce que la pf du siège est censé répondre aux prmiers paquets reçus.
Vous voulez des packets capture ?

chris4916

J'avoue ne pas comprendre l'intérêt d'utiliser pfSense uniquement comme serveur VPN.
Pourquoi dans ce cas ne pas juste installer un serveur OpenVPN sur une machine dédiée dans avoir à se trimballer toute la couche pfSense ?

nc21

merci pour l'intérêt porté à mon pb.
d'abord ce n'est pas directement mon choix.
et puis cela se justifie par le fait que l'admin principal n'a pas de compétence Linux, il veut une interface graphique qu'il connait (comme il y en a déjà sur tous ses sites distants)
il voulait un cluster et connait le mécanisme CARP sur pfSense.
voulait un système de mise à jour, intégrant l'OS et les packages.
çà le rassurait dans l'interopérabilité (implémentation identique de part et d'autres)
de plus l'interface identique permet de comparer le paramétrage.
de plus le remplacement de FW par du pfSense est bien prévu.

sinon vous avez une idée à mon PB ?
A notez qu'entre temps j'ai mis à jour la version de pfSense d'autres sites distants sans PB.
J'ai voulu faire de même pour le site posant pb, çà n'a rien changé…

chris4916

@nc21:

sinon vous avez une idée à mon PB ?
A notez qu'entre temps j'ai mis à jour la version de pfSense d'autres sites distants sans PB.
J'ai voulu faire de même pour le site posant pb, çà n'a rien changé…

Si tu as du pfSense de partout et que c'est l'interface connue de l'admin, pourquoi pas ;)

J'essaie de reformuler le problème de manière simple car à la lecture de ton post initial, je ne comprends pas tout :

24 sites distants doivent se connecter en VPN (OpenVPN) à un site central.
ça fonctionne pour 23 sites mais pas pour le 24ème

Ce que je ne comprends pas bien, c'est si ce 24ème site est le seul à avoir 2 interfaces WAN.
Si c'est le cas et que, comme je comprends, cette nouvelle interface FTTH est supposée remplacer l'interface SDSL, pourquoi ne pas se simplifier la vie en passant tout sur l'interface FTTH, qui a garder le SDSL uniquement en fail-over ?
Mais c'est de toute façon une question annexe puisque coté configuration OpenVPN, tu décris l'interface que tu veux utiliser… sauf qu'il y a une pratique courante qui consiste à avoir le serveur OpenVPN qui écoute sur le port localhost et de faire du forward des différentes interfaces WAN quand il y en a plusieurs.

Bref, ce serait intéressant de décrire cet aspect des choses.

Coté central, as-tu fait des essais en mode "simple" c'est à dire sans CARP, pfSync etc... pour t'assurer que le problème ne vient pas de la configuration du cluster ou des VIP ?

nc21

Merci pour tes conseils.
J'ai trouvé hier soir, tard…
le pb ne venait pas du site distant mais bien de la config du cluster du siège.
l'OpenVPN du noeud maître écoutait sur l'IP de son interface au lieu d'écouter sur la VIP !
t'étais sur la bonne piste.
Merci.
Super boulot ce que vous faites.

PS: plusieurs sites avec 2 WAN et elles sont bien en Failover.

chris4916

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

Finalement le problème était assez simple et tenait en quelques lignes 8)

Question subsidiaire, par curiosité : pourquoi le choix OpenVPN pour faire du site-to-site plutôt que de l'IPSec qui, pour le moment, bénéficie de AES-NI au contraire de OpenVPN ?

nc21

Oui c'est vrai (j'ai voulu être exhaustif comme avec le formulaire) déjà que c'est du support en Best Effort, j'ai voulu donné toutes les infos (mais trop d'infos tue l'info)
En fait moi aussi j'aurais fait de l'IPSEC, mais l'Admin avait commencé à mettre çà en place tout seul, il s'est formé seul sur pf avec des tutos et il en a trouvé 1 sur OpenVPN…
le seul truc pas mal avec l'OpenVPN c'est qu'il y a un process par site et on peut en redémarrer juste 1, avec IPSEC si le process déconne (racoon /charon (en 2.2.x) / je ne sais pas son nom en 2.3), faut couper tous les tunnels :'(
pour le support des instructions AES-NI il faut que ce soit forcément un proc Intel ?
sur les sites distants, ils ont des boitiers Alix avec des proc AMD, mais sans carte d'accélération matériel.
et au siège c'est un proc Intel Atom Processor C2358 (1M Cache, 1.70 GHz)

jdh

Malgré le formulaire, il manquait des détails, que je reprends ici :

Siège :
Internet <-> Firewall (DMZ) <-> cluster pfSense <-> réseau interne

Le cluster de pfSense concentre les tunnels OpenVpn des sites distants

Sites distants :
Internet <-> pfSense <-> réseau local

Problématique :
1 site distant ne se connecte pas alors que les autres sont OK

Pour cette description, on voit un cluster de pfSense (sur le site central).
Il faut être très attentif, du fait de CARP, il est important que chaque pfSense écoute bien sur la VIP (Virtual IP) et non sa propre WAN address !
Néanmoins cela aurait entrainé un non fonctionnement général …

Concernant les liens sites à sites, bien qu'on puisse utiliser OpenVpn pour cela, il est bien plus fréquent d'utiliser Ipsec.
Il y a les contraintes habituelles lié à NAT (NAT traversal), bien connu avec Ipsec.
Mais on peut aussi 'interopérer' : les sites distants n'ont pas obligation d'être de même type (Fortinet, WatchGuard, Stormshield, ...)

Concernant le support des instructions AES-NI, il faut regarder la (bonne) doc : https://doc.pfsense.org/index.php/Are_cryptographic_accelerators_supported qui donne le support pour OpenVpn et Ipsec.
Et c'est assez normal de s'y intéresser sur un 'concentrateur' ...

chris4916

@nc21:

Oui c'est vrai (j'ai voulu être exhaustif comme avec le formulaire) déjà que c'est du support en Best Effort, j'ai voulu donné toutes les infos (mais trop d'infos tue l'info)

C'est un peu aussi mon avis ;)
Mais c'est sûr qu'il est difficile de trouver le juste milieu entre en dire le strict minimum et tout (ou presque) détailler. Surtout que ce n'est souvent que lorsque tu as trouvé la solution que tu te rends compte qu'il y avait soit trop de détails inutiles soit que malgré avoir pensé tout expliquer, ça passait à coté du point finalement en cause ;)
Bref, ce n'est pas important. ::)

pour le support des instructions AES-NI il faut que ce soit forcément un proc Intel ?
sur les sites distants, ils ont des boitiers Alix avec des proc AMD, mais sans carte d'accélération matériel.
et au siège c'est un proc Intel Atom Processor C2358 (1M Cache, 1.70 GHz)

Non, il y a des AMD avec du support AES-NI. Par exemple, chez PCengines, ça.
De plus, je n'ai pas suivi ça de très près pour le moment faute de temps mais il semble que le support de AES-NI au niveau de OpenVPN évolue.

Il ne faut pas non plus faire une fixation sur cette fonctionnalité : par exemple mettre AES-NI sur le chemin critique de ton design si c'est pour derrière connecter les sites en ADSL, ça ne présente pas beaucoup d'intérêt à cause du coté asymétrique des débits qui ne te permettra pas de tirer parti de l'accélération apportée par AES-NI.
En VDSL (proche du DSLAM), SDSL ou FTTH, c'est autre chose 8)

jdh

trop d'infos tue l'info

C'est un problème de logique :
pas d'infos = pas de compréhension = pas d'aide possible !
pas assez d'infos = compréhension incomplète = nécessité de demander à compléter.

Il vaut, donc, bien mieux trop d'infos que pas d'infos !
Le seul défaut d'avoir trop d'infos est que le lecteur soit obligé de faire le tri.
C'est vraiment gênant quand il y a des logs de 100 lignes (dont seules 3 lignes ont de l'intérêt).

Mais, on le voit très régulièrement, trop nombreux sont les débutants qui, soit ne fournissent pas d'infos, soit n'en fournissent pas assez.
Je passe sur ceux qui ne fournissent pas d'infos : on se demande s'ils veuillent être aider parce que c'est assez stupide de croire que la seule question pourrait avoir une réponse !
Ceux qui n'en fournissent pas assez font 'leur' tri : ils mettent ce qui, à leur yeux, a de l'intérêt, mais comme ils sont débutants, ils passent à côté d'informations qui sont utiles !

Donc il vaut bien de lire trop d'infos.