Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    OpenVPN Client <-> Serveur - Pas de ping si gateway différente.

    Scheduled Pinned Locked Moved Français
    7 Posts 3 Posters 2.0k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Z
      zeltragh
      last edited by

      Bonjour,

      Je post ce message car après pas mal de temps a me prendre la tête bah ça veut pas….Je m'explique.

      J'ai deux pfsense :

      PFsense-VPN: Connexion sdsl , installation et configuration avec le pfSense 2.2.4 puis mise a jour en 2.3.2.

      PFsense-Fibre: Connexion Fibre , installation et configuration avec le  pfSense 2.3.1 puis mise a jour en 2.3.2 ( pour voir si cela resout le souçis ou non)

      Description du problème:

      Sur le PFsense-Fibre

      Suivant la configuration de la passerelle de mes postes dans mon réseau d'entreprise que je joint avec le client openvpn , je ping ou non ces derniers depuis mon client vpn extérieur.

      PFsense-Fibre en passerelle >>> Je ping

      PFsense-VPN en passerelle >>> Je ping pas

      Freebox en passerelle >>> Je ping pas

      Overthebox en passerelle >>> Je ping pas

      Sur le PFsense-VPN

      PFsense-Fibre en passerelle >>> Je ping

      PFsense-VPN en passerelle >>> Je ping

      Freebox en passerelle >>> Je ping

      Overthebox en passerelle >>> Je ping


      Il y a t'il un paramètre que j'ai manqué ? Ou y a t'il un bug sur la distribution 2.3.x ?

      Merci a vous de m'avoir lu

      En espérant trouver la solution avec votre aide.

      Zeltragh

      1 Reply Last reply Reply Quote 0
      • C
        chris4916
        last edited by

        Tout d'abord, confirmes-tu (car ce n'est pas évident dans ton explication ou alors je ne comprends pas) que tes 2 pfSense sont configurés en VPN peer-to-peer ?
        Ensuite, je ne comprends pas cette histoire de passerelle "client".

        En gros, ça n'a rien à voir. Sur ton réseau local les clients doivent avoir une passerelle par défaut qui dépend de la topologie du réseau et du n'est pas sensé modifier ça. Tu peux bien sûr avoir d'autres routes et donc d'autres passerelles en fonction des destinations.

        Par exemple si ta passerelle par défaut te donne accès à internet mais que ton serveur VPN est sur une autre IP, cette IP sera la route annoncée lorsque tu voudras joindre le site distant.
        Ceci peut être fait soit par diffusion des routes via DHCP (par exemple) ou alors, mais c'est moins efficace, avec une route sur l'équipement qui a la default gateway.

        Bref, pour répondre à ta question, il faut que tu décrives un peu mieux la topologie de ton réseau.

        Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

        1 Reply Last reply Reply Quote 0
        • Z
          zeltragh
          last edited by

          J'ai produis un petit shema:

          Pour faire simple si je me connecte depuis l’extérieur vers mon réseau d'entreprise avec le premier pfsense que j'ais monté ( pfsense-vpn) , tous les postes de mon réseau d'entreprise seront joignables peut importe leur ip de passerelle vers le web.

          Si je me connecte depuis l'extérieur vers mon réseau d'entreprise avec mon second pfsense qui est plus récent (pfsense-fibre) , tous les postes de mon réseau qui on pfsense-fibre en passerelle web seront joignable .  En revanche ceux qui n'ont pas ip de passerelle web définie ou qui on free , ovh ou overthebox en passerelle ne seront tout simplement pas joignables a travers le vpn (pas de ping , pas de vnc).

          1 Reply Last reply Reply Quote 0
          • C
            chris4916
            last edited by

            ok, il faut que je regarde de plus près ce schéma auquel je ne comprends rien  :-[

            Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

            1 Reply Last reply Reply Quote 0
            • B
              baalserv
              last edited by

              Si j'ai bien compris, tu a donc 2 passerelles sur ton lan Pf1 et Pf2 ; tes postes du lan ont pf1 comme passerelle, donc ça fct avec les clients Ovpn qui se connecte à Pf1 mais pas avec ceux qui se connecte à pf2.

              Quand on configure un serveur Ovpn en peer-to-peer ont attribu un réseau intermediaire au tunnel, les clients distant récupère donc une ip dans ce tunnel lors de leur connexion. Il te faut un N° de réseau de tunnel différent sur tes 2 Pf.

              Ca ne fct pas avec pf2 car ni les postes ni pf1 ne connaissent l'existance ni la route pour joindre le tunnel de pf2.

              Il faut donc soit sur les postes soit sur pf1 indiquer la route à suivre pour joindre le tunnel de pf2 et donc les postes clients distant ovpn.
              Le plus simple est d'ajouter une static route sur pf1 qui dis : le réseau du tunnel de pf2 est joignable via l'ip lan de pf2.

              Tu peut faire un essaie en ajoutant manuellement la route sur le poste cible de tes test ;)

              Cela s'appelle un problème de route retour, c'est assez courrant ^^ Le client ovpn envoie la requette au pc cible du lan, le pc cible reçoie la demande qui lui arrive avec l'ip que le client ovpn à reçu lors de sa connexion dans le réseau du tunnel. Mais, le pc cible ne sais pas qu'il doit envoyer la reponse à l'ip lan de pf2 donc il l'envoie à la seule passerelle qu'il connais soit l'ip lan de pf1 (tu suis toujours?) MAIS pf1 ne sais pas non plus que l'ip du client ovpn est joignable via l'ip de lan de pf2 donc il transmet à la seule passerelle qu'il connait soit l'ip de la box puis la passerelle du Fai et donc la réponse va se perdre dans les limbes d'internet et n'arrive jamais à l'ip du client ovpn qui à envoyer la demande.

              Si la connerie humaine fournissait de l'énergie, la Terre serait sauvée …

              1 Reply Last reply Reply Quote 0
              • Z
                zeltragh
                last edited by

                Tout d'abord baalserv et chris4916 pour vos réponses rapides.

                Je comprend bien vos explications.

                Je viens de faire un test avec un des postes qui ne répond pas initialement.
                Il a pour passerelle Overthebox (192.168.136.223).
                De base je ne ping pas depuis l'extérieur.
                Je viens donc de faire "  route add 20.30.40.0 mask 255.255.255.0 192.168.136.221 -p " sur cette machine.

                20.30.40.0 pour le reseau vpn

                255.255.255.0 pour le masque du reseau vpn

                192.168.136.221 pour l ip de la passerelle fibre sur laquel mon client vpn a initié une connexion.

                -p pour persistant

                ^^ Là je ping bien depuis mon client vpn !! C'est le début du bonheur !!

                –---

                Cependant je me questionne sur le fait que le pfsense-vpn ( donc le pf1) lui n'est pas dérangé pour résoudre les ip des postes de l'entreprise quand je me connecte dessus bien qu'ils ne soient pas tous sur la passerelle du pf1.

                M'enfin... déjà cela me retire une bonne grosse problématique ! MERCI A VOUS !

                Plus qu'a pondre une petite GPO pour ajouter la route  8)

                1 Reply Last reply Reply Quote 0
                • C
                  chris4916
                  last edited by

                  @zeltragh:

                  Plus qu'a pondre une petite GPO pour ajouter la route  8)

                  Tout simplement DHCP ça le fait aussi.
                  Les GPO aussi, mais que pour les clients Windows  ::)

                  Ils sont assez fort chez Microsoft pour faire des trucs propriétaires quand même  :P

                  Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.