Problème / Question Routing / VPN

Lolight

Merci pour ta réponse Chris4916

Effectivement, j'introduis la partie hors VPN et je pense que le problème viens de la.
J'ai essayé de faire un schéma assez clair de l'infra sans trop détailler bien que ce soit une maquette j'utilise quand même des donnée et des équipement bien réel.

J'ai aussi essayé de produire quelque chose de plutôt propre afin de faciliter la compréhension.
Je n'ai pas tenus compte du NAT dans le shéma mais idéalement le réseau LAN RPI serais sur un subnet de type 172.168.X.0/25

Network.png_thumb

chris4916

En tous cas, c'est beaucoup (beaucoup) plus clair comme ça.
Je vais relire tes précédents posts à la lumière de ce schéma.
Ce qui apparaît déjà - visuellement - clair, c'est que pfSense est tr_ès probablement la route par défaut pour les équipement sur le site A alors que la route par défaut sur le site B est plutôt le modem/routeur derrière le switch. Il faut donc que celui-ci sache que la route vers 172.16.0.0/25 passe part le RPI, en tous cas pour les sessions issues du site B.

Lolight

Hello,
Content que ça te permette de mieux visualiser les choses.
Le but avant de pouvoir atteindre mes host de test étant de pouvoir atteindre l'ip interne configuré sur la patte eth0 de mon RPI (192.168.0.80).
J'ai pas la main sur les Hote de test pour le moment, mais leurs rôle sera simplement de répondre à des pings émis du CentOS(côté Lan pfSense).

Si il arrive a joindre l'hôte, le retour ne devrais pas poser de problème, enfin j'espère, peut être que je ne vois que la partie émergé de l'iceberg ;D

chris4916

je pense, comme toi, que si tu arrives à joindre le serveur cible, il n'y a pas de problème de "retour".
En revanche, je ne suis pas certain que le ping soit l'arme absolue pour les tests, sauf si tu as une vision précise de ce qui est fait en terme de ICMP (et de règles de FW en général)

Dois-je déduire de ton schéma que l'adresse publique de l'équipement réseau situé sur le site B est 80.10.xx.xxx ?

Et donc, dans ma compréhension, nous avons:

sur l'équipement en 80.10.xx.xxx (site B) , une redirection vers 192.168.0.80 (interface du RIP) pour le(s) ports utilisés par OpenVPN
ça permet d'établir un tunnel entre les sites A et B (le choix du netmask /25 pour le réseau du tunnel est surprenant mais pourquoi pas…)
une fois le tunnel établi, pfSense connaît la route vers 192.168.0.0/24 (celle-ci passe par le tunnel donc la GW est 172.16.1.xxx)
les machines sur le réseau A ayant pfSense comme gateway par défaut, les requêtes vers 192.168.0.x vont passer par le tunnel sans qu'il soit besoin de définir de route statique, à la main, de part et d'autre.

J'ai juste jusque là ?

Si oui:

je ne comprends pas quel est le problème (au delà du fait que la réponse au ping n'est pas nécessairement activée partout
je ne comprends pas pourquoi nous aurions un filtrage de la part de 80.10.xx.xxx (même si physiquement ça passe par là, nous sommes "dans" le tunnel n'est-ce pas ?)

Je continue ma lecture ;-)

chris4916

A noter que si tu veux faire des tests de B ver A, il faut que sur la gateway par défaut des machines du réseau B il y ait une route "en dur" qui précise que la route vers 172.16.0.0/25 passe par 192.168.0.80

Je suppose que cette gateway est l'interface interne de l'élément qui se situe à la frontière avec le WAN (l'équipement qui a 80.10.124.xxx en adresse publique ;-) )

Lolight

@chris4916:

Dois-je déduire de ton schéma que l'adresse publique de l'équipement réseau situé sur le site B est 80.10.xx.xxx ?

Et non justement c'est ça qui me fais penser que ça part se perdre dans les méandre du web.
Aucune de mes deux ip public ne correspond a cette adresse qui me retourne "Packet filtered"
Il y a aussi le traceroute qui me met sur cette voie la.

@chris4916:

Et donc, dans ma compréhension, nous avons:

sur l'équipement en 80.10.xx.xxx (site B) , une redirection vers 192.168.0.80 (interface du RIP) pour le(s) ports utilisés par OpenVPN

Exactement, sauf l'ip public qui ne correspond mais dans l'idée oui c'est ça.

@chris4916:

ça permet d'établir un tunnel entre les sites A et B (le choix du netmask /25 pour le réseau du tunnel est surprenant mais pourquoi pas…)

Je compte le changé, j'ai eu un soucis de compréhension en lisant la doc et j'ai cru qu'il fallait que j'alloue un sous réseau pour le tunnel.
M'enfin c'est comme ça pour la maquette, j'y touche plus mais quand je le mettrais en place ça changera surement

@chris4916:

une fois le tunnel établi, pfSense connaît la route vers 192.168.0.0/24 (celle-ci passe par le tunnel donc la GW est 172.16.1.xxx)

Tu pense ?
Quand je fais un traceroute depuis le LAN pfSense vers 192.168.0.80 j'obtiens ceci :

 1  192.168.1.1  1.220 ms  0.952 ms  0.997 ms
 2  * 80.10.124.140  2.332 ms !X *
 3  * * 80.10.124.140  1.979 ms !X
 4  80.10.124.140  1.928 ms !X * *
 5  * 80.10.124.140  1.666 ms !X *
 6  * * *
 7  * * *

Si il passais par le tunnel il devrais me retourner 172.16.0.2 qui est le bout du tunnel.. Non ? Ou au moins 172.16.0.1 (Patte LAN pfSense, puis 172.16.0.2 Patte Tun0 du RPI)

@chris4916:

les machines sur le réseau A ayant pfSense comme gateway par défaut, les requêtes vers 192.168.0.x vont passer par le tunnel sans qu'il soit besoin de définir de route statique, à la main, de part et d'autre.

J'ai juste jusque là ?

Normalement oui mais du coup je suis pas sur avec le traceroute.

@chris4916:

Si oui:

je ne comprends pas quel est le problème (au delà du fait que la réponse au ping n'est pas nécessairement activée partout

je ne comprends pas pourquoi nous aurions un filtrage de la part de 80.10.xx.xxx (même si physiquement ça passe par là, nous sommes "dans" le tunnel n'est-ce pas ?)

Je continue ma lecture ;-)

Il n'y a pas de filtrage, il y a bien un FW mais j'ai ajouté une règle pour ne rien filtrer sur la destination 192.168.0.80 donc le RPI.
Puis le tunnel est établis donc tout devrais passer dedans.

Je fais des ping, cas l'objectif est de faire du monitoring avec notre ami Nagios, et il me semble que le check_host_alive passe par de l'icmp :)

Je te donne beaucoup de lecture et peut être un mal de tête, encore et encore merci :)

chris4916

Donc oui il y a bien un truc dans le potage ;D car depuis le client VPN, une fois le tunnel établi, la route vers le(s) réseau(x) connecté(s) au serveur devrait être connue et publiée.

Je n'ai pas fait de test avec OpenVPN de pfSense (mais j'en ai déployé plein d'autres ;)) et si l'advertising est configuré correctement, alors cette route est publiée.
Dans le cas contraire, pas étonnant que ça ne marche pas.

Pour en revenir au subnet associé au tunnel lui même, dans le cas d'un tunnel qui sert à raccorder 2 réseaux, un netmask en /30 suffirait puisque ça contient 2 hosts, soit un par extrémité du tunnel ;)
Mais c'est du détail et ne gène en rien le fonctionnement

Une fois que tu as établi le tunnel, vérifie quelles sont les routes de part et d'autre avant de faire plus de tests ;-)

Lolight

Hello,
Je viens vous donner des new, je suis toujours bloqué mais je n'ai plus ce prblème de de "Packet filtered"

Alors niveau VPN j'ai monté un tunel Site to Site avec OpenVpn.
Les configuration sont sensiblement les même.

Mon tunnel est bien établis sur OpenVPN et le client RPI arrive à ping le LAN pfSense.
Pour l'instant c'est comme avant.

Je n'arrive pas à joindre dans l'autre sense mon LAN RPI.
J'arrive quand même à ping le tunnel VPN.

Je pense qu'ici c'est un simple problème de route.
Je vais donc étudier le problème dans le sens LAN pfSense vers LAN RPI

Pour commencer la route par défault de mon LAN pfSense est pfSense.
Donc les paquet devrais être bien acheminé vers le pfSense.
Ensuite niveau pfSense la route pour joindre mon réseau 192.168.0.X est bien le tunnel VPN
Donc la aussi ça devrais être bon.

Niveau route sur le RPI j'ai du mal a saisir si la configuration est bonne ou pas.


Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
10.0.8.0        *               255.255.255.0   U     0      0        0 tun0
172.16.0.0      10.0.8.1        255.255.255.128 UG    0      0        0 tun0
192.168.0.0     *               255.255.248.0   U     0      0        0 eth0

Faut-il que j'ajoute une route pour lui dire tout se qui arrive de tun0 a destination de 192.168.0.0/21 doit sortir sur eth0 ?

chris4916

le serveur VPN est ici pfSense. Lorsque le client établi le tunnel, le serveur informe le client que la route vers le réseau (LAN) du serveur passe par le tunnel.
Dans ce que tu veux faire, c'est un poste sur le LAN du serveur VPN qui veut joindre un poste sur le LAN du réseau "client"

Ceci nécessite une route décrivant le tunnel comme route pour le réseau client, ce qui semble être le cas.
Peux-tu afficher ici les routes présentes sur pfSense une fois le tunnel établi ?

Lolight

Merci Chris pour l'aide que tu m'as apporté sur Skype/Mail.
Mon problème n'es pas résolus mais je vais reposer les choses dans un nouveau topic avec un titre explicite et une présentation concrète des routes règles FW.
J'ai tellement manipulé tout ça que vous serez perdu et perdrais du temps avec des shéma plus à jour ou mal décris.