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

    openvpn et VPN SSL unidirectionnel

    Scheduled Pinned Locked Moved Français
    5 Posts 3 Posters 616 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.
    • B
      bwen
      last edited by bwen

      Bonjour,

      Je fais du "sd-wan" avec un pfsense et ca fonctionne parfaitement hormis un petit point:
      Mon lien principal est une FTO lan to lan donc aucun soucis. Mon lien de secours est une FTTH sur laquelle j'ai monté un VPN SSL vers mon site central (server VPN SSL sur stormshield), le pfsense est donc le client.
      Le probleme est donc que lorsque je suis en mode dégradé sur mon lien de secours, mes postes derrière le pfsense donc coté client peuvent bien communiquer avec les postes de mon site central (derriere le serveur vpn) mais l'inverse ne fonctionne pas. J'ai bien forcé la route dans le tunnel au niveau du stormshield, suite a cela je vois bien mes paquets passer sur l'interface tun1 du stormshield mais ils n'arrivent pas jusqu'au pfsense (verif avec tcpdump). Ils doivent donc se perdre dans le tunnel, je ne sais pas. Est ce que quelqu'un aurait une idée sur la question svp?

      Merci

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

        @bwen said in openvpn et VPN SSL unidirectionnel:

        Ils doivent donc se perdre dans le tunnel

        Il y a de la lumière dans le tunnel ?
        Plus sérieusement je ne comprend pas comment des paquets peuvent se perdre sur un lien apr ailleurs fonctionnel. Si ils quittent l'interface tun1 et ne parviennent pas sur l'interface de pfsense, soit un équipement les bloquent soit il ne prennent pas la bonne direction en sortie de l'interface tun.
        A moins que la vérification coté pFsense ne soit pas fiable et que les paquets soient simplement filtrés. Mais vous semblez sûr de votre affaire.

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

          Merci de ta réponse.J'ai refait le test car ton post m'a mis le doute mais j'arrive au même resultat... pas de trace d'icmp sur aucune des interfaces du pfsense, il n'y a pas d’équipement entre les deux, le tunnel se fait direct du stormshield au pfsense et les paquets ne sont pas bloqués par une règle de firewall du pfsense ni du SNS.... Je vais refaire le point avec mon opérateur sur les routes.

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

            Vous êtes devant votre installation, et vous savez exactement qu'est ce qui est branché et à quoi.

            Mais, moi, simple lecteur, je ne comprends rien ! Et d'autres doivent l'être tout autant ...

            Un schéma serait très UTILE ...

            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
            • B
              bwen
              last edited by

              Je te rassure, je n'en suis pas a mon premier essai en terme d'infra réseau et je ne comprends rien non plus même devant mon installation, je vous ai passé des détails encore plus tordus comme le fait que je vois revenir la réponse icmp par le tunnel mais le SNS les bloque car il n'a pas vu passer la requête initiale (c'est pourtant lui qui la route vers tun1)... bref c'est trop compliqué dans l’état pour être résolu ici même avec un schéma. Je pense même changer complètement la topologie car même si c’était fonctionnel comme ça, ça n'est pas propre, le stormshield ne permet pas de faire une route vers ses interfaces vpn depuis l'interface web, j'ai été obligé de la faire en ligne de commande, le problème est peut être tout simplement la. Le sujet peut etre clos. Merci

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