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.
    • F
      fabienfs
      last edited by

      Bonjour,

      J'ai un problème avec mon pfSense qui est client OpenVPN tun. Le réseau distant est un 10.25.5.0/27. Le réseau du tunnel est 10.25.10.0/24.
      Le réseau local est 10.30.100.0/24.

      Le problème est que quand je ping une machine distante, exemple 10.25.5.5 via ma machine en local qui à par exemple l'adresse 10.30.100.50, je ne reçois pas de réponses à mes ping.

      J'ai fait une règle NAT outbound pour que sur l'interface client OpenVPN la source 10.30.100.0/24 qui veut joindre 10.25.5.0/27 NAT avec l'adresse de l'interface ovpnc1 (10.25.10.6).

      Si je fait un packet capture dans pfSense sur l'interface client OpenVPN ovpnc1 quand je ping, je vois ceci :

      01:35:50.411811 IP 10.25.10.6 (adresse interface client OpenVPN (ovpnc1), NAT) > 10.25.5.5: ICMP echo request, id 17408, seq 695, length 40
01:35:50.454515 IP 10.25.5.5 > 10.25.10.6: ICMP echo reply, id 17408, seq 695, length 40

      Donc le ping passe bien, la machine distante me réponds, mais après, pfSense ne renvoi pas à mon pc 10.30.100.50 ce que l'interface client OpenVPN (ovpnc1) 10.25.10.6 à reçu. Comme si elle ne savait pas ou envoyer le packet à "dénater".

      Si je regarde dans la table NAT de pfSense, le NAT est correct :

      10.30.100.50:1 (mon pc) -> 10.25.10.6:52636 (adresse de l'interface client OpenVPN qui NAT) -> 10.25.5.5 (pc distant que je ping)

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

      Si je fais un ping de mon pc sur l'adresse de l'interface (10.25.10.6) la j'ai bien des réponses par contre…
      Aussi, si je ping 10.25.5.5 depuis l'outil Ping Diagnostic de pfSense, ça ping si je met en source adresse l'interface OpenVPN client ovpnc1. C'est dès qu'on tente de ping depuis une autre interface que je n'ai pas de réponse.

      Dans les règles firewall pour l'interface OpenVPN client (ovpnc1), j'autorise tout.

      Schéma simplifié :

      Une idée d'ou le problème pourrait venir ?
      Merci pour votre aide :)

      Fabien

      1 Reply Last reply Reply Quote 0
      • Y
        ycuaz
        last edited by

        Bonjour,

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

        Chief Executive

        http://www.1fogenilac.fr

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

          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é.

          1 Reply Last reply Reply Quote 0
          • 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
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.