[Résolus] VPN Site To Site OpenVpn

Lolight

Bonjour,
Pour les personne qui on suivis mon topic précédent, vous savez plus ou moins mon niveau de compétence, pour les autres, je suis en LP informatique.

Dans le cadre de mon stage en entreprise, je maquette une architecture réseau qui a pour but de relier dans un premier temps deux site distant puis plusieurs par la suite.

Le liens entre ces site distant se font via VPN, plus précisément OpenVpn en mode Site to Site avec une authentification par certificats.

Je travail actuellement sur une maquette qui me pose problème.

Le shéma de la maquette est le suivant :


ClientA(1)------------(2)PfSense(3)---------------(4)Debian(5)---------(6)ClientB
          172.16.0.0/25               10.0.8.0/24           192.168.0.0/21

Les numéraux entre parenthèse définissent les interface, je m'en servirais un peut plus bas.
N'y prêtez pas attention pour l'instant.

Ceci étant dans la réalité le shéma est bien différent.
Je pense que je n'ai pas besoins de le décrire car mon tunnel entre PfSense et Debian est établis (corrigez moi si je me trompe).

Je pense que je dois quand même préciser que mon pfSense est en mode routeur, tout les flux du réseau passe par lui, il a donc deux carte réel.

A contrario pour le Debian il est sur le réseau, ça ne change pas grand chose mis à part le fait que le fait que je doive rajouter une route sur ClientB pour lui dire de s'adresse a Debian pour joindre 10.0.8.0/24 et 172.16.0.0/21.

J'avais avec Chris vérifié mes route mes configuration FW, tout étais bon mais j'ai pas la suite monté une autre maquette en utilisant mon Debian, ça m'a finalement mis un peut le bordel dessus, je suis donc repartis sur une base propre en le réinstallant.
Voilà pour la petite histoire.

Bon la description de mon problème now !
Mon Client A n'arrive pas à joindre mon Client B et inversement. (Par joindre je parle de ping)
Le tunnel VPN étant étables et les FW étant correctement configuré.
Je suppose que cela viens des routes (Oui oui Chris je recule plus que j'avance)

Si nous reprenons mon schéma un peux plus haut.

Mon ClientA 172.16.0.X a pour route :
default gw (2)
Destination 172.16.0.0/25 -> gw (2)

Mon pfSense ou R1
Destination 192.168.0.0/21 -> gw (4)
Destination 172.16.0.0/25 -> gw (2)
Destination 10.0.8.0/24 -> gw (3)

Mon Debian ou R2
Destination 172.16.0.0/25 -> gw (4)
Destination 192.168.0.0/21 -> gw (5)
Destination 10.0.8.0/24 -> gw (4)

ClientB 192.168.0.x
default gw (5)
Destination 192.168.0.0/21 -> gw (5)

Etat du problème actuel :

Je pense que mon soucis viens de mes routeurs la configuration des client étant.. basique :D
Plus précisément au niveau du routage vers le réseau 10.0.8.0 qui est mon pont.
Bizarrement si réalise des ping entre mes deux extrémité de tunnel, c'est à dire des ping de 10.0.8.1 vers 10.0.8.2 et inversement ça fonctionne correctement.

Je ne sais pas trop se qui ne va pas. Après avoir verrifier 10 fois que j'ai bien activé le forwarding ainsi que mes rêgles iptables.

Après avoir ajouté la commande suivante sur iptables le ping du clientB vers A fonctionne.
L'inverse n'es pas valable en revanche.

iptables -t nat -A POSTROUTING -j MASQUERADE

J'espère avoir bien posé le problème.

Dans l'attente d'une réponse, merci pour votre lecture.

chris4916

dans une connexion site à site, les routes ne se maintiennent habituellement pas au niveau du client sur le LAN mais au niveau des équipements en bordure de celui-ci (idéalement sur la machine qui sert de "edge router")

Lorsque le tunnel est établi sur la machine qui fait office de defautl gateway (le cas de pfSense sur le site A), il est uniquement nécessaire que pfSense sache que la route vers 192.168.0.0.25 passe par 10.0.8.x (l'extrémité distante du tunnel VPN.

Sur le site B, c'est un peu plus difficile car le client VPN n'étant pas la gateway par défaut, les paquets à destination de 172.16.0.0/21 n'atteignent pas le tunnel.
Une route sur chaque client est possible mais c'est parfois un peu lourd à gérer. Une autre solution consisterait à ajouter la route "en dur" sur l'équipement qui fait office de default gateway. Ce n'est pas efficace d'un point de vue réseau car les paquets vont atteindre la default gateway avant de retourner vers le tunnel mais ça fonctionne.

Last but not least: il n'y a pas, de mon point de vue, de raison de publier des routes vers le réseau qui fait office de tunnel. Dans un mode site à site, ce réseau peut être réduit au strict nécessaire (en terme de netmask) et n'être accédé que pas les 2 tenant du tunnel. Les équipement que chaque LAN n'ont pas besoin d'en avoir connaissance (sauf si on veut jouer à faire des ping de chaque extrémité mais je ne vois pas l'intérêt dans le cas décrit ici.

Lolight

Hello,
Je repasse, j'ai essayé de retirer les routes inutiles (j'ai d'ailleurs édit mon post initial) afin d'éviter une lecture inutile de celui-ci.

J'ai toujours pas trouvé, cependant j'avais des soucis de stabilité de tunnel qui étais surement du a ma bande passante, je suis donc passé en protocole tcp à la place de l'udp.

J'ai depuis un tunnel stable, une bonne chose de fait bien que le loup qui empêche la communication entre mes deux site soit toujours présent.

Petit edit, la situation a un peut évolué, avec une commande iptables ça marche dans 1 sens, le détail au dessus :)

Lolight

Hello,
Je viens vous faire un feedback concernant mon problème de ping dans un sens et pas dans l'autre.
Après de longue recherche en compagnie de notre amis Chris49 que je remercie énormément pour l'aide apportée.
Celui-ci a mis le doigts sur la source de mon problème qui étais en fait le fais que je devais définir mon client dans le tab "Client Override"

J'ai simplement définis dans cet onglet le remote network en laissant les champs tunnel et local vide.
Si vous les remplissez vous avez peut être de soucis lors du lancement du client celui-ci recevra les routes en double.
(Je pense qu'il les envois en double car que les ai définis coté serveur puis côté client Override, et il faut le faire sur l'un des deux seulement.)

A la suite de quoi mon client c'est connecté, il étais biensure toujours capable de joindre mon Lan côté PfSense mais mon Lan pfSense étais lui aussi capable de joindre mon client.

Le traffic fonctionne donc dans les deux sens ce n'étais pas un problème d'iptables au final.

Merci au personne qui m'on aidé sur mon topic précédent comme celui-ci.