Problème connexion OpenVPN site-à-site



  • Contexte : milieu professionnel, je suis administrateur débutant, et en phase de test

    Besoin : L'idée est de connecter un site à un autre grâce à un routeur 4g, pour palier aux coupures qui arrivent régulièrement de notre FAI. Ce routeur sera couplé à un pfsense monté sur un petit PC. La connexion se fait en OpenVPN site-à-site avec clé pré partagée.

    Schéma : réseau A(192.168.2.X/24)------(192.168.2.1/24)pfsense(10.0.0.11/24)------(10.0.0.1/24)box(ip publique)------internet------(ip publique)box 4g(10.10.10.1/30)------(10.10.10.2/30)pfsense(192.168.200.1/24)------(192.168.200.X/24)réseau B

    Le réseau du tunnel est en 172.16.0.0/30

    WAN (modem/routeur/box) : comme précisé dans le schéma, une box pro d'un coté et une box 4g de l'autre. J'ai configuré du NAT sur les 2 routeurs, le port 1194 étant redirigé vers le pfsense.

    LAN : Il y le réseau A et le réseau B uniquement, qui sont des réseaux de tests. Par contre il faut noter que le réseau 10.0.0.0/24 est utilisé dans l'entreprise. Du DHCP est configuré pour le réseau B

    DMZ : pas de DMZ

    WIFI : pas de wifi

    Autres interfaces : NA

    Règles NAT : Comme expliqué plus il y a du NAT en 1:1

    Règles Firewall : c'est simple, IPV4 any any/any sur le WAN, LAN et OpenVPN

    Packages ajoutés : rien n'a été ajouté

    Autres fonctions assignées au pfSense : Le pfsense ne sert qu'à ça pour l'instant

    Question :Mon tunnel OpenVPN se créé bien. Lorsque je suis sur le réseau A, je peux pinger 192.168.200.1 (interface LAN du pfsense), mais je ne peux pas pinger une autre machine du réseau B. Dans l'autre sens, même chose, à partir du réseau B, je peux pinger le 192.168.2.1, mais je ne peux pas aller plus loin.

    Pistes imaginées

    Recherches : J'ai d'abord pensé à des problèmes de firewall, j'ai donc tout ouvert sans résultat. J'ai également désactivé les pare feux des 2 postes qui me servent à faire les tests.
    Ensuite, j'ai pensé à un problème de routes, j'ai donc inscrit à la main les routes sur les PC. ex : route add -P 192.168.200.0 mask 255.255.255.0 192.168.2.1

    Logs et tests : dans tous les cas, le résultat est le même puisque je ne peux pas pinger l'intérieur du réseau.

    En tout cas merci d'avance pour vos lumières



  • @chuck2kill said in Problème connexion OpenVPN site-à-site:

    Règles NAT : Comme expliqué plus il y a du NAT en 1:1

    Pourquoi faire ?

    Ce routeur sera couplé à un pfsense monté sur un petit PC
    Pas idéal.

    Ensuite, j’ai pensé à un problème de routes
    C'est probable vu l'empilage de nat entre les deux réseaux. Vous ne devriez pas avoir à mettre des routes sur les PC. Vous ne devriez pas avoir tout ces NAT. Je n'ai ni le temps ni la patience de démêler vos problèmes de routage fort probable. Juste un détail : n'oubliez pas les routes "retour". Le filtrage des box. Ne laissez pas votre wan en any any accept. Activez ls logs sur les règles et regardez les logs de Pfsense de part et d'autre.

    Pour de l'interconnexion de site IPSec est souvent préférable. Bref un projet qui cumule de nombreuses sources d'ennuis potentiels.



  • Bonjour, J'ai créé une connexion vpn via Opevpn. Tout ceci marche très bien. Le seul problème, c'est quand je connecte un client au serveur, je ne plus accéder à mon réseau local et à internet. Comment faire ???? Merci de vos réponses.
    Tutuapp 9Apps Aptoide



  • @zamakli said in Problème connexion OpenVPN site-à-site:

    Bonjour, J'ai créé une connexion vpn via Opevpn. Tout ceci marche très bien. Le seul problème, c'est quand je connecte un client au serveur, je ne plus accéder à mon réseau local et à internet. Comment faire ???? Merci de vos réponses.

    Ouvrez votre propre discussion et fournissez de la documentation sur votre configuration. Pour le moment votre question est : Pourquoi çà marche pas ?
    Mais nous ne savons pas de quoi vous parlez.



  • tout d'abord désolé pour la réponse tardive.
    Je sais que c'est un projet qui n'est pas idéal, j'aurais préféré passer en ipsec, mais le pfsense distant doit passer par une box 4g pour la connexion, ce qui implique une ip dynamique. Par conséquent le tunnel en openVPN me paraît plus indiqué.

    Par ailleurs, je pense avoir résolu une partie de mon problème. En effet, j'ai activé les interfaces correspondant au VPN (OPT1 sur les 2 pfsense en 172.16.0.1/30 et 172.16.0.2/30) et je les ai assignées en tant que passerelles par défaut.

    Maintenant j'ai une connexion stable entre les 2 pfsense. De plus, les machines sur mon réseau distant peuvent pinger toutes les machines sur mon réseau local. Malheureusement l'inverse n'est pas vrai. Les machines du réseau local ne peuvent pas aller plus loin que le pfsense distant.

    Ma question est la suivante: Le fait de passer par une connexion openVPN site à site peut-il empêcher la réciprocité des pings?



  • @chuck2kill
    Non, rien n'interdit dans un lien vpn, toutes technos confondues, le fonctionnement d'icmp.



  • @ccnet
    je me posais cette question du fait de la configuration serveur client. Mais j'ai certainement oublié quelque chose.

    Ce qui m'étonne, c'est que l'accès fonctionne dans un sens mais pas dans l'autre.
    J'ai d'ailleurs fait fonctionner un wireshark sur le pc distant. On voit bien la requête arriver, mais le PC ne renvoie pas de réponse. Je ne vois pas de raison autre que des règles de pare feu restrictives. Et pourtant tout est ouvert.



  • @chuck2kill

    • J’ai d’ailleurs fait fonctionner un wireshark sur le pc distant. On voit bien la requête arriver, mais le PC ne renvoie pas de réponse. Je ne vois pas de raison autre que des règles de pare feu restrictives. Et pourtant tout est ouvert.

    Si le paquet icmp reply ne part pas du pc, ce n'est pas Pfsense qui l'en empêche. Firewall local peut être .... Mauvaise interprétation de la capture. Si c'était le cas, le blocage des paquets icmp reply serait visible dans les logs (si ils sont actifs) de Pfsense.



  • @ccnet
    sur wireshark je vois les ICMP request avec, d'après mes souvenirs, (reply not found). J'ai donc pensé au firewall de la machine, mais il est désactivé. D'ailleurs, j'ai testé ce pc sur un autre réseau et le ping fonctionne.

    De plus, j'ai installé un autre PC pour jouer le rôle du poste distant, et là, même problème, pas de ping.

    En tout cas merci de prendre un peu de temps pour répondre à mes questions.



  • @chuck2kill
    Que donne les logs du firewall (pfsense) pour l'interface où sont sensé arriver les icmp reply ?
    Vérifiez aussi le fonctionnement de arp.
    Vous confirmez qu'en sens inverse c'est fonctionnel ?
    Le côté ennuyeux de votre config est que d'un côté vous avez une interface logique Openvpn sur Pfsense et de l'autre un client d'Openvpn. Dans quel sens ce n'est pas fonctionnel (j'ai la flemme de tout relire) ?



  • @ccnet
    En ce qui concerne les logs, voici le résultat:
    0_1528870522374_2018-06-13 08_10_07-pfSense.localdomain - Status_ System Logs_ Firewall_ Normal View.png

    192.168.12.50 est mon client distant et 172.16.0.1 est l'interface du tunnel.
    On voit donc qu'il y a un request mais pas de reply.

    Voici ensuite la table ARP:
    0_1528870676630_2018-06-13 08_12_20-pfSense.localdomain - Diagnostics_ ARP Table.png

    Je confirme effectivement que c'est fonctionnel dans le sens client -> serveur.
    C'est le sens serveur -> client qui ne fonctionne pas.



  • Bon,

    J'ai trouvé le problème, après plusieurs recherches, il semblerait que le problème venait du pare feu du PC. Je suis passé sur un PC en Win 10 et j'ai enlevé le pare feu. Maintenant le ping passe dans tous les sens.

    A priori, sur l'ancien PC en win7, même si j'avais enlevé le pare feu, il devait y avoir une option qui m'avait échappée.

    En tout cas merci pour votre aide, maintenant il ne me reste plus qu'à affiner la configuration, mais le plus important est que mon VPN soit opérationnel.



  • J'avoue que j'avais un peu du mal à comprendre comment un tunnel "site-à-site" peut être impacté par le fonctionnement d'un poste de travail sur un des LAN.
    De toute évidence, maintenant que tu as trouvé la cause du problème, celui-ci était du à ta manière de vérifier que le VPN fonctionne correctement ☺

    Un peu comme lorsque la mesure elle même perturbe le résultat 😎



  • Oui c'est vrai. comme quoi il ne faut négliger aucune piste dans la recherche de solutions. C'est une bonne leçon.
    🕵


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy