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

    PfSense OpenVPN problème de routage, NAT

    Français
    4
    20
    3.9k
    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.
    • F
      fabienfs
      last edited by

      @ycuaz:

      Bonjour,

      Pourrais tu fournir les masque de réseaux associés à ta maquette ?

      Hello ycuaz,

      J'ai rajouté les masques aussi sur le schéma

      @ccnet:

      Une idée de pourquoi mon packet ne revient pas sur ma machine avec le dénat ?

      Les routes retour nécessaires sont elles en place ? Au passage je pense que le nat ne sert à rien. Tout devrait se régler avec un routage approprié.

      Hello ccnet,

      La route de retour existe il me semble puisque lors du packet capture, on voit que le packet de retour à l'air de rester bloquer au 10.25.10.6 (adresse interface ovpnc). Pour arriver à destination il aurait encore du continuer son chemin jusqu'à 10.30.100.1 (adresse de l'interface du réseau ou j'ai mon pc) puis 10.30.100.50 (adresse de mon PC). Et pour ca les routes existent. Si je regarde dans "Diagnostics" > "Routes" j'ai bien toutes les routes nécessaires :

      Je pense que le NAT est nécessaire puisque le réseau distant 10.25.5.0/27 ne connait pas les réseaux 10.30.x.x. Il connait juste les deux réseaux 10.25.5.0/27 et 10.25.10.0/24. Pour ça que je NAT avec ce réseau là. Ce n'est pas correct ?

      merci pour vos réponses :-)

      Bonne journée

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

        Pour OpenVPN Server et client 'roadwarrior', nul besoin de NAT !

        Pour OpenVPN Site-2-Site, je suis surpris par l'utilisation de NAT : cela n'est pas du tout nécessaire.

        Le premier point est d'avoir des routes installées de chaque côté : utilisation de push route conseillée
        Le deuxième point est de tester par ping et par traceroute (tracert -d sous Windows).

        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:

          Pour OpenVPN Server et client 'roadwarrior', nul besoin de NAT !

          Pour OpenVPN Site-2-Site, je suis surpris par l'utilisation de NAT : cela n'est pas du tout nécessaire.

          Le premier point est d'avoir des routes installées de chaque côté : utilisation de push route conseillée
          Le deuxième point est de tester par ping et par traceroute (tracert -d sous Windows).

          Bonjour jdh,

          Du côté de la configuration serveur, j'ai 2 push route :

          push "route 10.25.5.0 255.255.255.224"
push "route 10.25.10.0 255.255.255.0"

          Avec ca, le client connait les réseaux distants.
          Mais le serveur lui ne connait pas les routes du réseau qui émet les ping request (10.30.100.0/24). Il y a une possibilité de faire un push route pour le serveur ? Que le client puisse annoncer ses réseaux ?

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

            pfSense, en serveur, sait envoyer un "push route" qui sera bien interprété par le client (XP, Seven, …).
            pfSense, en client, sait-il bien interpréter le "push route" ?
            Il ne mange pas de pain de

            • ajouter, à la main, la route vers le serveur OpenVPN (en site-2-site, il n'y a que 2 ip qui communiquent)
            • vérifier pas à pas (ping et traceroute) là où ça coince

            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:

              pfSense, en serveur, sait envoyer un "push route" qui sera bien interprété par le client (XP, Seven, …).
              pfSense, en client, sait-il bien interpréter le "push route" ?
              Il ne mange pas de pain de

              • ajouter, à la main, la route vers le serveur OpenVPN (en site-2-site, il n'y a que 2 ip qui communiquent)
              • vérifier pas à pas (ping et traceroute) là où ça coince

              J'ai ajouté les routes à la main, mais ça ne change rien (vu qu'elles existent déjà comme montré dans mon screenshot ci-dessus).
              Concernant le ping et traceroute, je l'ai fait dans tout les sens :-( J'ai même précisé ou ça coinçait dans mon premier post.
              La j'ai enlever ma règle NAT outbound, et si je fait un packet capture sur mon interface ovpnc1, j'ai ceci :

              18:01:47.015553 IP 10.30.100.50 > 10.25.5.5: ICMP echo request, id 1, seq 37, length 40

              Mais forcément pas de réponse car 10.25.5.5 ne connait pas le réseau 10.30.100.0/24. Comment faire pour que les machines distantes sachent ou répondre si je n'utilise pas de NAT ? C'est la que quelque chose m'échappe…
              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.

              1 Reply Last reply Reply Quote 0
              • 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