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

    problème de vpn site to site depuis maj 2.7.1 et 2.7.2

    Scheduled Pinned Locked Moved Français
    open vpnpfsense 2.7.2site to site
    8 Posts 3 Posters 1.2k 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.
    • E
      eckeagle
      last edited by

      Bonjour

      Jusqu’à la version 2.7 j'utilisais openvpn avec l'authentification 'préshared key' qui marchait très bien .Avec la version 2.7, j'ai vu que la fonction 'préshared key' allait être enlever pour des questions de sécurité.
      Donc suite à maj 2.7.1 et 2.7.2, j'ai décidé de passer à authentification tls/ssl et la commence mes galères.Donc aujourd'hui j'ai réinstallé complètement mes deux routeurs de site distant pfsense en version 2.7.2.
      Pour le vpn site to site la connexion et l'authentification s'effectue correctement sauf j'ai gros problème de routage de mes vlan de site A vers site b et inversement. Les postes de mon site A n'arrive pas à communiquer avec les poste de mon site b et inversement.Bizarrement, j'arrive à pinger mes machines de site A depuis le routeur de site b.

      Personnellement je pense à un bug dans openvpn

      Si quelqu'un à une autre idée Merci d'avance

      Cordialement
      Eckeagle

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

        Usuellement, pour le vpn des nomades, on utilise OpenVPN (avec certificat plus user/mdp), et pour le vpn site à site, on utilise Ipsec.

        Je vous encourage à passer à Ipsec.

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

        E 1 Reply Last reply Reply Quote 0
        • E
          eckeagle @jdh
          last edited by

          @jdh

          Bonjour

          Pour information, au niveau d'internet je suis en ip dynamique sur mes deux sites. J'ai lu qu'il n'est pas recommandé d'utiliser ipsec quand on est en ip dynamique aprés je peux avoir mal lu...

          Cordialement

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

            Il est préférable de faire du vpn site à site sur des ip fixes, mais ce n'est pas pour autant qu'il faut faire de l'OpenVPN.

            Des lignes Internet en ip dynamiques, c'est généralement de l'ADSL, alors le débit du lien inter-site sera limitée au débit montant !

            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
            • L
              labu73
              last edited by

              Bonsoir,

              Je suis exactement dans la même situation, avec le site client sur Starlink donc pas d'IP fixe. J'avais un lien shared keys nickel et je tente de passer en tls/ssl

              Pas de réel souci pour la mise en place sauf que seul le pfsense client parvient à pinger les IPs LAN du serveur, en envoyant des trames depuis 10.0.10.2 (adresse Tunnel).

              Voici les captures dans le VPN du client

              Pings OK depuis tunnel
              22:41:54.411732 IP 10.0.10.2 > 192.168.16.10: ICMP echo request, id 38092, seq 0, length 64
              22:41:54.475057 IP 192.168.16.10 > 10.0.10.2: ICMP echo reply, id 38092, seq 0, length 64
              22:41:55.419270 IP 10.0.10.2 > 192.168.16.10: ICMP echo request, id 38092, seq 1, length 64
              22:41:55.483186 IP 192.168.16.10 > 10.0.10.2: ICMP echo reply, id 38092, seq 1, length 64
              22:41:56.444606 IP 10.0.10.2 > 192.168.16.10: ICMP echo request, id 38092, seq 2, length 64
              22:41:56.507325 IP 192.168.16.10 > 10.0.10.2: ICMP echo reply, id 38092, seq 2, length 64

              Pings NON OK depuis lan
              22:42:03.566776 IP 192.168.68.1 > 192.168.16.10: ICMP echo request, id 63188, seq 0, length 64
              22:42:04.574230 IP 192.168.68.1 > 192.168.16.10: ICMP echo request, id 63188, seq 1, length 64
              22:42:05.579436 IP 192.168.68.1 > 192.168.16.10: ICMP echo request, id 63188, seq 2, length 64

              Les même captures dans le VPN côté serveur

              23:41:54.448923 IP 10.0.10.2 > 192.168.16.10: ICMP echo request, id 38092, seq 0, length 64
              23:41:54.449256 IP 192.168.16.10 > 10.0.10.2: ICMP echo reply, id 38092, seq 0, length 64
              23:41:55.456870 IP 10.0.10.2 > 192.168.16.10: ICMP echo request, id 38092, seq 1, length 64
              23:41:55.457176 IP 192.168.16.10 > 10.0.10.2: ICMP echo reply, id 38092, seq 1, length 64
              23:41:56.481752 IP 10.0.10.2 > 192.168.16.10: ICMP echo request, id 38092, seq 2, length 64
              23:41:56.482068 IP 192.168.16.10 > 10.0.10.2: ICMP echo reply, id 38092, seq 2, length 64

              Aucune trace des trames venant du LAN client.

              Au départ je supposais un problème de routage au départ, mais les trames sont capturées.
              Ensuite, ne voyant pas les trames à l'arrivée je ne vois pas ce qui pourrait être fait côté serveur.

              Vos suggestions sont les bienvenues.

              Merci d'avance

              1 Reply Last reply Reply Quote 0
              • E
                eckeagle
                last edited by eckeagle

                Bonjour

                En ce qui me concerne j'ai réglé mon problème. Je n'ai pas passée à par ipsec comme le suggérais JDH
                Mais j'ai suivie ce poste:
                https://forum.netgate.com/topic/186219/site-to-site-openvpn-routing-issue
                J'ai donc paramétré une règle CSO sur mon serveur openvpn et depuis tout marche nickel.

                1 Reply Last reply Reply Quote 0
                • L
                  labu73
                  last edited by

                  Bonjour,

                  J'ai maintenant une configuration fonctionnelle à un détail près.

                  Le fonctionnemeent client vers serveur est nickel, les ordinateurs sur le LAN côté client ont bien accès aux adresses sur le LAN côté serveur.

                  Par contre, je ne parviens pas à ce que les ordinateurs sur le LAN côté serveur atteignent le LAN client.

                  Le Ping depuis le PfSense serveur sur des cibles LAN client fonctionne, aussi bien en sélectionnant any que LAN.

                  Le LAN serveur est en 192.168.16.0/24 et le LAN client en 192.168.68.0/24

                  Un ping du Pfsense Serveur vers 192.168..68.3 réussit avec une adresse source 192.168.16.1.

                  Un traceroute depuis un ordinateur sur le LAN serveur en 192.168.16.3 vers 192.168.68.3 sort directement sur la fibre et non le tunnel.

                  Je précise que le serveur a 2 serveurs OpenVPN, un en client to site pour les itinérants et le site to site.

                  Je pensais que le CSA ferait le taf.
                  Capture d'écran 2024-03-10 104308.png

                  Des recommandations?

                  Merci d'avance

                  L 1 Reply Last reply Reply Quote 0
                  • L
                    labu73 @labu73
                    last edited by labu73

                    Problème réglé en ajustant le firewall, le LAN serveur accède bien au LAN client.

                    Il me reste un souci, j'avait une règle NAT pour rediriger un port spécifique depuis le WAN serveur vers une IP client. Cette règle fonctionnait en Site to Site Shared Key mais je ne parviens pas à la faire fonctionner sur le VPN TLS/SSL.

                    Capture d'écran 2024-03-11 112308.png

                    Qu'est ce que le passage en TLS/SSL peut avoir à voir avec cela?

                    Des Idées?

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