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

    OPENVPN und mehrere Standorte

    Scheduled Pinned Locked Moved Deutsch
    24 Posts 4 Posters 2.9k 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.
    • A
      achim55 @viragomann
      last edited by

      @viragomann

      supi, jetzt hat es geklappt :-)
      Besten Dank für die Hilfestellung 👍 👍

      1 Reply Last reply Reply Quote 0
      • JeGrJ
        JeGr LAYER 8 Moderator
        last edited by

        Weil bei solchen Multi-Point VPN Geschichten immer wieder die gleichen Fragen/Argumente für oder gegen eine bestimmte Variation des Aufsetzens mit OpenVPN kommt wie bspw. @Gladius

        Ja, man kann das ganze natürlich mit einem einzelnen Server auf einem Port abdecken und muss dann nicht 3 VPN Server Instanzen (in diesem Fall in der Loc. RE) pflegen. Kann man. Und die pfSense Doku schreibt das auch konkret.

        Aber: Die Doku schreibt auch ganz konkret wie es mit der Shared Key Methode läuft und dass diese eine andere Art und Alternative dazu ist. Die Vorteile überwiegen gerade in einem Datacenter Setup dabei für mich gerade deshalb weil:

        • Nur mit Shared Key meines Wissens bislang FRR/Quagga möglich ist (OSPF und Co. für einfacheres Routing oder Failover)
        • Mit 3 Server Instanzen Multicores (gerade in DC Umgebungen stehen da meistens nicht gerade Miniatur Router) sinnvoller genutzt werden können. Gerade bei 3 Site2Site Tunnel mit ordentlich Traffic ist dadurch bessere Nutzung der CPU möglich, ohne bei 3 ausgealsteten Verbindungen gleich einen einzelnen Kern zum Glühen zu bringen
        • "Ausfall" eines Servers per se ist eher ungewöhnlich, was aber gar nicht so ungewöhnlich ist, sind Änderungen die an einer Verbindung vorgenommen werden müssen, die einen spezifischen Tunnel betreffen. Dann macht es absolut Sinn, dass ich nur diese Verbindung editieren muss und dann entsprechend nur dieses Ende neu starte während alle anderen Verbindungen sauber weiter laufen.

        Dazu kommt dass bei einem Shared SSL/TLS Setup mit 3 "Clients" man gerade bei komplexen Routings durch die IRoutes (also client specific overrides und Co.) wieder so viel Zusatzkonfiguration hat, dass der Gewinn - nur einen Tunnel zu haben - fast schon wieder aufgeraucht wird. Gerade wenn man nicht nur Verbindungen des Typs Client(s) -> Server Netzwerk hat, sondern aus dem Server Standort auch auf die Clients muss, müssen Routen umständlich eingepflegt werden und man hat auch nicht die Möglichkeit, jede Verbindung einzeln (als Interface) mit Regeln zu bestücken.

        Daher für mich (wie gesagt hauptsächlich bei Firmen- oder DC/RZ Verbindungen mit mehreren Tunneln) nach wie vor das sinnvollste Setup mit einzelnen Tunneln pro Site. Das sind aber natürlich nur meine Gründe und 2 Cent, da darf jeder seinen eigenen Euro reinwerfen und das anders machen 😃

        Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

        If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

        G 1 Reply Last reply Reply Quote 0
        • G
          Gladius @JeGr
          last edited by

          @jegr said in OPENVPN und mehrere Standorte:

          Daher für mich (wie gesagt hauptsächlich bei Firmen- oder DC/RZ Verbindungen mit mehreren Tunneln) nach wie vor das sinnvollste Setup mit einzelnen Tunneln pro Site.

          Danke für diese Hinweise. Da spricht ein Mann mit viel Erfahrung zum Einsatz von OpenVPN im Firmenumfeld.
          Die genannten Vorteile mehrerer Tunnel-Instanzen hatte ich als privater Anwender nicht so im Blickfeld,
          wobei ich die bessere Lastverteilung schon gesehen habe.

          LG

          DTAG (VDSL100) / Speedport Entry2 (Modem) / Jetway NF792i-3160 / Version 2.8.0-RELEASE (amd64)

          JeGrJ 1 Reply Last reply Reply Quote 0
          • JeGrJ
            JeGr LAYER 8 Moderator @Gladius
            last edited by

            @gladius War auch gar nicht konkret als Kritik gedacht, sondern eher als Aufklärung, warum das heute durchaus noch die favorisierte Variante sein kann, wenn man mit größeren Strukturen murmeln "darf" 😉

            Ist auch nicht wirklich sooo schön, wenn man da bspw. für 20 Außenstellen 20 Tunnel aufbauen und konfigurieren muss, vor allem wenn die dann noch crossover verbunden sind. Aber gerade dadurch - und bei Tunnel Anzahlen von >4 - lohnt sich das oft schon alleine deshalb, um einen Multicore besser auszunutzen. Auch wenn man meistens nicht unbedingt die mega Bandbreiten schaufelt, addiert sich dann doch bei ~20 Links auf einem 4-Kerner die Last pro Kern (5 Tunnel pro Kern) durchaus zusammen. AES-GCM hilft da aber schonmal - wenn man beide Enden kontrolliert und aktuell hält. Inzwischen ist aber auch wieder IPSEC dank routbarem Interface eine veritable Alternative geworden (die wir aber noch testen müssen).

            Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

            If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

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