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

    PfSense OpenVPN problème de routage, NAT

    Français
    4
    20
    4.0k
    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.
    • C
      ccnet
      last edited by

      10.25.5.5 veut répondre au ping de 10.30.100.50, mais cette machine ne connait pas ce réseau.. Donc la machine va interroger va envoyer la réponse ping à la passerelle par défaut qui est un autre router qui ne connait pas ce réseau non plus.

      La machine n'interroge pas la passerelle par défaut. Elle lui envoie les paquets parce que justement elle ne possède pas d'autre indication. Je n'ai pas vraiment le temps de décortiquer votre histoire. Votre diag me semble bon mais il faut en tirer les conclusions. Vite fait il me semble que 10.25.5.5 devrait ne pas employer la passerelle par défaut mais l'interface de votre tunnel pour répondre. Donc une route qui passe par 10.25.10.1 pour atteindre 10.30.100.0/24. Ceci sans nat ajouté. J'ai regardé ca vite fait, je n'ai pas beaucoup  de temps.

      1 Reply Last reply Reply Quote 0
      • F
        fabienfs
        last edited by

        @ccnet:

        La machine n'interroge pas la passerelle par défaut. Elle lui envoie les paquets parce que justement elle ne possède pas d'autres indication. Je n'ai pas vraiment le temps de décortiquer votre histoire. Votre diag me semble bon mais il faut en tirer les conclusions. Vite fait il me semble que 10.25.5.5 devrait ne pas employer la passerelle par défaut mais l'interface de votre tunnel pour répondre. Donc une route qui passe par 10.25.10.1 pour atteindre 10.30.100.0/24. Ceci sans nat ajouté. J'ai regardé ca vite fait, je n'ai pas beaucoup  de temps.

        Effectivement dans un routage logique on devrait avoir 10.30.100.50 > 10.25.10.1 > 10.25.5.5.

        J'ai enlever la règle NAT que j'avais mise et maintenant, mon ping va encore moins loin qu'avant si j'analyse avec un packet capture.

        Si je ping et que je lance un packet capture sur mon interface du réseau 10.30.100.50 j'ai bien ceci :

        10:15:57.092025 IP 10.30.100.50 > 10.25.5.5: ICMP echo request, id 1, seq 16, length 40

        Par contre si je fait un packet capture sur l'interface ovpnc1, la je n'ai déjà plus rien. Comme si il ne trouvais pas la route de 10.25.5.5.

        Pourtant si je regarde dans Diagnostics > Route, j'ai bien ma route. Mais qui à comme passerelle 10.25.10.5 :

        Je ne comprends pas pourquoi il n'arrive pas à aller plus loin. Pourquoi le ping bloque alors que la route existe ? Une idée ? :)

        Merci

        1 Reply Last reply Reply Quote 0
        • J
          jdh
          last edited by

          Est ce bien utile d'avoir ces routes ?

          • la route 10.25.10.1/32 est déjà incluse dans 10.25.10.0/24 !

          La seule route utile est le réseau distant via l'ip (tunnel) du firewall distant.

          ex :
          zone G : lan = 192.168.55.0/24; fw lan 192.168.55.254/24; fw tunnel 10.0.8.2
          zone D : lan = 192.168.133.0/24; fw lan 192.168.133.1/24; fw tunnel 10.0.8.4

          de G vers D, la route est 192.168.133.0/24 via 10.0.8.4
          de D vers G, la route est 192.168.55.0/24 via 10.0.8.2

          à adapter …

          Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

          1 Reply Last reply Reply Quote 0
          • F
            fabienfs
            last edited by

            @jdh:

            Est ce bien utile d'avoir ces routes ?

            • la route 10.25.10.1/32 est déjà incluse dans 10.25.10.0/24 !

            La seule route utile est le réseau distant via l'ip (tunnel) du firewall distant.

            ex :
            zone G : lan = 192.168.55.0/24; fw lan 192.168.55.254/24; fw tunnel 10.0.8.2
            zone D : lan = 192.168.133.0/24; fw lan 192.168.133.1/24; fw tunnel 10.0.8.4

            de G vers D, la route est 192.168.133.0/24 via 10.0.8.4
            de D vers G, la route est 192.168.55.0/24 via 10.0.8.2

            à adapter …

            Je n'ai jamais créer une seule de ces routes… C'est pfSense et OpenVPN qui m'ont pondus ces routes... Je voudrais bien supprimer les routes plus précises, mais comment ? Je ne vois pas de moyens de suppression.

            Je ne vois pas ce que je peux adapter ne sachant pas modifier ces routes générées toutes seules

            1 Reply Last reply Reply Quote 0
            • J
              jdh
              last edited by

              Je n'ai jamais créer une seule de ces routes…

              Donc les routes se créent par réception des "push route" !

              Je pense qu'il y a trop de route créées : 3 réseaux semblent accessibles !

              Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

              1 Reply Last reply Reply Quote 0
              • F
                fabienfs
                last edited by

                @jdh:

                [Donc les routes se créent par réception des "push route" !

                Je pense qu'il y a trop de route créées : 3 réseaux semblent accessibles !
                [/quote]

                J'ai un peu fait le ménage, notamment dans la configuration client OpenVPN et maintenant je n'ai plus que ceci :

                10.25.5.0/27	10.25.10.5	UGS	0	44	1500	ovpnc1	 
10.25.10.0/24	10.25.10.5	UGS	0	10	1500	ovpnc1	 
10.25.10.1/32	10.25.10.5	UGS	0	0	1500	ovpnc1	 	 
10.25.10.10	link#16	UHS	0	0	16384	lo0

                Mais mon problème reste identique quand au ping. Ça cale toujours au même endroit

                1 Reply Last reply Reply Quote 0
                • J
                  jdh
                  last edited by

                  Cela fait toujours 3 réseaux accessibles via cette gateway ! Ce sont les push route qu'il faut nettoyer !

                  Moi, je configurerai le serveur sans aucune push route, puis "connexion" puis vérif des routes côté client, …

                  Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

                  1 Reply Last reply Reply Quote 0
                  • F
                    fabienfs
                    last edited by

                    @jdh:

                    Cela fait toujours 3 réseaux accessibles via cette gateway ! Ce sont les push route qu'il faut nettoyer !

                    Moi, je configurerai le serveur sans aucune push route, puis "connexion" puis vérif des routes côté client, …

                    Ok j'ai mis un route-nopull dans la config client et à présent je n'ai plus qu'une GW allant vers le réseau distant :

                    10.25.5.0/27	10.25.10.5	UGS	0	0	1500	ovpnc1	 
10.25.10.5	link#16	UH	0	27	1500	ovpnc1	 
10.25.10.6	link#16	UHS	0	0	16384	lo0

                    De ce côté la ça parait propre. Par contre mon ping de 10.30.100.50 vers 10.25.5.5 reste bloqué après la sortie de la première interface LAN (réseau 10.30.100.50/24) :

                    14:48:35.115193 IP 10.30.100.50 > 10.25.5.28: ICMP echo request, id 1, seq 30, length 40

                    Si je fais un packet capture sur l'interface ovpnc1, je ne vois rien arriver. Ni de ping request ni de ping reply. Comme si il ne savait pas quelle route prendre… Pourtant comme montré ci-dessus, il sait que pour accéder au réseau 10.25.5.0/27 il doit passer par 10.25.10.5. Tiens au fait pourquoi il veut utiliser 10.25.10.5 comme GW ? Ce n'est pas 10.25.10.1 qu'il faudrait ?

                    1 Reply Last reply Reply Quote 0
                    • J
                      jdh
                      last edited by

                      Côté client, vous refusez les routes, pourquoi pas, mais au moins ajouter la seule bonne route nécessaire sinon pfSense ne sait pas par où passer !

                      Si je fais un packet capture sur l'interface ovpnc1, je ne vois rien arriver. Ni de ping request ni de ping reply. Comme si il ne savait pas quelle route prendre… Pourtant comme montré ci-dessus, il sait que pour accéder au réseau 10.25.5.0/27 il doit passer par 10.25.10.5. Tiens au fait pourquoi il veut utiliser 10.25.10.5 comme GW ? Ce n'est pas 10.25.10.1 qu'il faudrait ?

                      La bonne passerelle est, forcément, l'ip tunnel du côté opposé : 10.25.10.5 !

                      Attention, il est bien sûr nécessaire d'avoir des Firewall > Rules nécessaires dans l'onglet voulu (OpenVPN) !

                      Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

                      1 Reply Last reply Reply Quote 0
                      • F
                        fabienfs
                        last edited by

                        @jdh:

                        Côté client, vous refusez les routes, pourquoi pas, mais au moins ajouter la seule bonne route nécessaire sinon pfSense ne sait pas par où passer !

                        La bonne passerelle est, forcément, l'ip tunnel du côté opposé : 10.25.10.5 !

                        Attention, il est bien sûr nécessaire d'avoir des Firewall > Rules nécessaires dans l'onglet voulu (OpenVPN) !

                        Donc si la bonne GW est 10.25.10.5, je suis bon au niveau des routes avec ce que j'ai montré dans mon post précédent, non ?

                        Dans le firewall, pour l'interface OpenVPN, ovpnc1 et LAN, j'autorise tout :

                        Sans succès :-\

                        1 Reply Last reply Reply Quote 0
                        • J
                          jdh
                          last edited by

                          Il faut savoir interpréter la sortie de la commande 'route' (sous BSD) :
                          UH -> désigne un Host accessible
                          UGS -> désigne un réseau accessible par une Gateway

                          Le serveur sait-il bien accéder à une machine de ce réseau (étroit) 10.25.5.0/27 (soit de 10.25.5.1 à 10.25.5.31) ?

                          Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

                          1 Reply Last reply Reply Quote 0
                          • F
                            fabienfs
                            last edited by

                            @jdh:

                            Le serveur sait-il bien accéder à une machine de ce réseau (étroit) 10.25.5.0/27 (soit de 10.25.5.1 à 10.25.5.31) ?

                            Oui, si je ping depuis l'interface ovpnc1, j'ai bien des réponses aux ping.
                            C'est quand je ping depuis une autre interface (comme LAN) que ça ne fonctionne plus

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