OPENVPN und mehrere Standorte



  • Hallo,
    irgendwie habe ich da ein Denkfehler.

    Ich habe am Standort RE 3 OPENVPN Server laufen.
    Standort LÜ,BE und BÖ verbinden sich zu diesem und kommen auf das LAN 172.21.0.0.

    Von Standdort RE komme ich auch auf das LAN hinter LÜ,BE und BÖ.

    Soweit alles gut.

    Jetzt muss ich von Standort BE und BÖ auf das LAN LÜ kommen ( gelb eingezeichnet ) und wieder zurück.

    Und da liegt wohl mein Gedankenfehler, vermute ich.

    Ich habe unter, Benutzerdefinierte Optionen, bei dem OPENVPN Server BE folgendes eingetragen.
    push "route 192.168.1.0 255.255.255.0";
    route 192.168.1.0 255.255.255.0;
    push "route 10.168.101.0 255.255.255.0";
    route 10.168.101.0 255.255.255.0;

    Und unter dem OPENVPN Server LÜ:
    push "route 192.168.2.0 255.255.255.0";
    route 192.168.2.0 255.255.255.0;
    push "route 10.168.102.0 255.255.255.0";
    route 10.168.102.0 255.255.255.0;

    Ich kann aber weder von LÜ nach BE bzw. umgekehrt pingen.
    BÖ lass ich erst einmal aus, bis die anderen Standorte funktionieren :-)

    Oder sollte ich lieber zusätzlich noch einen OPENVPN Server in LÜ aufsetzen und jeweils einen Client in BE und BÖ die sich dann mit LÜ verbinden ?

    Schöne Grüße

    0_1533826872487_vpn.png



  • @achim55 said in OPENVPN und mehrere Standorte:

    Ich habe unter, Benutzerdefinierte Optionen, bei dem OPENVPN Server BE folgendes eingetragen.

    Warum? Dafür gibt es doch die Felder "Remote Networks" und "Local Networks" in der GUI.
    Und wozu brauchst du die VPN-Tunnel Netze? Die interessieren dich doch gar nicht, du willst ja nur zum LAN dahinter.

    Bei Lü musst du die beiden LANs von BE und BÖ zu den "IPv4 Remote Networks" hinzufügen, alle in CIDR Notation und Komma-getrennt.
    Bei den andern beiden ist nur jeweils das LÜ LAN hinzuzufügen.

    Achte auch, dass die Firewall Regeln auf sämtlichen betroffenen Interfaces den Zugriff erlauben, auch die zwischengeschalteten VPN Interfaces.

    Grüße



  • @achim55 said in OPENVPN und mehrere Standorte:

    Oder sollte ich lieber zusätzlich noch einen OPENVPN Server in LÜ aufsetzen und jeweils einen Client in BE und BÖ die sich dann mit LÜ verbinden ?

    Wozu?

    Mit dem Server Mode "Peer to Peer ( SSL/TLS)" am Standort RE und der Nutzung von "Client Specific Overrides"
    ("iroute", "clientspezifische Routen") kann man bequem per GUI dieses Szenarium abbilden.

    Sind hier wirklich drei Server-Instanzen für den Standort RE notwendig? Was ist der Grund?



  • @gladius
    morgen.Ich trage die LANs mal so ein.
    0_1533889523015_IPv4.png
    Jedoch bin ich mir nicht sicher ob die Firewall Regeln so richtig sind.
    Dies sind die Regeln vom Standort RE
    2_1533889587296_WAN.png 1_1533889587295_LAN.png 0_1533889587295_OpenVPN.png



  • @gladius
    ich denke mir schon. Wenn eine Instanz ausfällt laufen noch die beiden anderen.



  • @achim55 said in OPENVPN und mehrere Standorte:

    Wenn eine Instanz ausfällt laufen noch die beiden anderen.

    Warum sollte das passieren?

    Mir erscheint deine Konfiguration für das geplante Szenarium ziemlich umständlich. Zur besseren Lastverteilung
    würde ich mehrere OpenVPN Server (mehr als einen CPU-Kern auf der Hardware vorausgesetzt) als Variante
    verstehen. Wenn deine Kiste abraucht, dein Provider ausfällt, usw. ist doch Schicht im Schacht.



  • @achim55
    Hallo,

    ich denke, wir sollten erst mal die bestehende VPN Konfiguration in Ordnung bringen.
    Erst weise bitte jeder VPN Instanz ein Interface zu. Das ist speziell nötig, wenn auf einem Host mehrere VPN Instanzen laufen, würde ich aber für ein vernünftiges Routing bei einer Site-2-Site immer empfehlen.
    Also zumindest am Standort RE sind 3 VPN Interfaces nötig.
    Interfaces > Assign. Wähle bei "Available network ports" die jeweilige VPN Instanz aus, klicke auf Add, dann das neue Interface öffnen, aktivieren und einen Namen deiner Wahl vergeben. Speichern und fertig.

    Ich weiß nicht, in welcher OpenVPN-Konfiguration du die gezeigten Netze eingetragen hast, aber Sinn macht das nirgends.

    Remote Netze sollte so aussehen (unter der Annahme, dass alle LANs /24 sind):
    RE:
    Server f. LÜ: 192.168.1.0/24
    Server f. BE: 192.168.2.0/24
    Server f. BÖ: 192.168.13.0/24

    LÜ: "172.21.0.0/24,192.168.2.0/24,192.168.13.0/24"

    BE: "172.21.0.0/24,192.168.1.0/24,192.168.13.0/24"

    BÖ: "172.21.0.0/24,192.168.2.0/24,192.168.1.0/24"

    Dann haben alle Seiten die Route, dass sie über RE mit den anderen kommunizieren können.

    Nachdem du in den Firewall Regeln alles nach überall hin erlaubst, können die Regeln nicht das Problem sein.
    Allerdings solltest du die WAN-Regeln schon auf die benötigten Zielports für OpenVPN einschränken. Nachdem du diese nicht genannt hast, kann ich auch nur mit einer allgemeinen Beschreibung dienen.
    Weil du mehrere Server auf RE laufen hast, müssen das auch mehrere Ports sein. Sinnvoller Weise nimmt man hier aufeinander folgende Ports, dann lässt sich das direkt in einer Regel umsetzen, anderenfalls kannst du alle verwendeten Ports einem Alias hinzufügen und diesen in der Regel verwenden.

    Mit dem zuweisen einzelner Interfaces zu den VPN Instanzen bekommst du auch in den FW-Regeln für jedes dieser einen Tab dazu, auf dem du die Regel definieren kannst.
    Das Interface "OpenVPN" ist eine Interface-Gruppe, der alle VPN Instanzen angehören. Regeln, die da angelegt sind, gelten also auf allen OpenVPN Interfaces. Nachdem du da ohnehin alles erlaubst, brauchst du auch keine neuen Regeln an den einzelnen Interfaces erstellen.

    Übrigens, die Diskussion ob man das mit einem Server + CSO oder mit mehreren Servern löst, halte ich für sinnlos. Für mich ist das reine Geschmackssache. Von der Systemauslastung macht es keinen unterschied, da benötigt einfach jede einzelne VPN-Verbindung Ressourcen und nachdem dies alles Site-2-Site VPNs sind, sind die ohnehin immer verbunden.
    Es sollte aber in dem Zusammenhang erwähnt werden, dass die Einserverlösung mit CSO nur mit SSL/TLS-Authentifizierung funktioniert und wir wissen nicht, ob die überhaupt eingesetzt wird.

    Grüße



  • @viragomann said in OPENVPN und mehrere Standorte:

    Es sollte aber in dem Zusammenhang erwähnt werden, dass die Einserverlösung mit CSO nur mit SSL/TLS-Authentifizierung funktioniert

    Nun, der Ersteller des Themas wird sich wohl vorher über die Konfigurationsmöglichkeiten von OpenVPN
    informiert haben. Wenn nicht, wird er früher oder später weitere Probleme bekommen.

    LG



  • @viragomann

    Hallo,
    irgendwo muss ich da noch einen Bug haben. Ich Kann aus dem LAN BE nicht nach dem LAN LÜ pingen :-(

    Die Ports laufen durch von 1194 bis 1196.
    0_1533974714961_port.png

    Zu der WAN Firewallregel noch eine Frage. Der untere Eintrag macht doch alles auf, oder ?
    0_1533974738444_FireWAN.png

    Und so habe ich die IPs eingetragen.

    0_1533974775627_lü.png

    BE
    0_1533974793030_be.png


    0_1533974803147_bö.png

    und die Interfaces sind auch online
    0_1533974878247_gateways.png

    Habe ich da noch etwas übersehen ?

    schöne Grüße



  • Ein Denkanstoß

    Damit bin hier raus.

    LG



  • @achim55
    Sorry, da hab ich wohl was verdreht bei meiner Empfehlung, BE u. BÖ.
    Diese musst du richtig stellen:

    BE: "172.21.0.0/24,192.168.1.0/24,192.168.13.0/24"

    BÖ: "172.21.0.0/24,192.168.2.0/24,192.168.1.0/24"

    (Habe es auch oben korrigiert, um Verwirrung zu vermeiden).



  • @viragomann

    Hallo,
    habe ich eingetragen. Nur jetzt geht es gar nicht mehr.☹
    Ich komme jetzt auch, von RE, nicht mehr auf die LANs von LÜ,BE und Bö.
    Umgekehr auch auch nicht von den Standorten auf RE.

    schöne Grüße

    von LÜ nach RE

    0_1534002719256_tracert-nach-RE.png

    von LÜ nach BE
    0_1534002744041_tracert-von-lü.png

    von RE nach LÜ
    0_1534003579709_vonre-lü.png

    von RE nach BE
    0_1534003371538_re-be.png



  • Also irgendwas stimmt da ganz gewaltig nicht.
    Offenbar die Netze. Du musst hier schon die richtigen Netze nennen, sonst kann eine Empfehlung natürlich nicht klappen.

    Das Traceroute von LÜ nach RE hat als ersten Hop 192.168.2.1 (pfsense.localdomain), doch diese IP hast du in deinem Netzplan bei BE angegeben.

    Bei LÜ nach BE hast du als 2. Hop 192.168.11.254. Dieses Netz fehlt komplett im Plan.
    Als Ziel hast du 192.168.1.4, aber das ist laut Plan nicht BE.

    Bei RE nach BE stimmt der VPN Tunnel nicht mit dem vom Plan.

    Also stelle bitte erstmal den Plan richtig, ansonsten kann man hier keine Empfehlungen abgeben. Überprüfe dabei auch nochmals, welcher VPN-Server mit welcher Gegenstelle verbunden ist.



  • @viragomann

    war mein Fehler. Habe die Screenshots vertauscht.

    Da die VPN Verbindung von BE nach RE klappte und ich auf das LAN hinter RE kam dachte ich das die Fritzbox uninteressant sei, da ja alles durch den Tunnel läuft.

    0_1534006761807_be_netzwerk.png

    RE nach BE
    0_1534006793019_RE-BE.png

    RE nach LÜ
    0_1534006845893_RE-LÜ.png

    BE nach LÜ
    0_1534006874589_BE-LÜ.png

    BE nach RE
    0_1534006925682_BE-RE.png

    ich kam ja vorher von allen Standorten auf das LAN hinter RE und auch von RE nach allen LANs hinter den Standorten.
    Nur eben halt nicht aus den LANs von BE, BÖ nach LÜ

    schöne Grüße



  • @achim55 said in OPENVPN und mehrere Standorte:

    ich auf das LAN hinter RE kam dachte ich das die Fritzbox uninteressant sei, da ja alles durch den Tunnel läuft

    Ist es auch, wenn der OpenVPN Endpunkt, also die pfSense das Standard-Gateway im LAN ist. Das Tracert ließ anderes vermuten.

    Offenbar hast du auf RE die "entfernten Netzwerke" der Server für LÜ und BE vertauscht. Diese werden nämlich jeweils in den andern Tunnel geroutet.

    Und auf BE funktioniert anscheinend das Routing gar nicht. Poste mal dies Einstellungen von da.



  • @viragomann
    Morgen,

    was mich wundert ist das unter Entfernte(s) IPv4 Netzwerk(e) nur noch das von RE,BÖ und BE steht.
    Muss da nicht auch das von LÜ rein bzw das von RE raus da diese ja ging? Oder übernimmt das das Routing von den Einträgen in BE für LÜ, weil dort ja die Adresse steht.

    Server f. LÜ: 192.168.1.0/24
    Server f. BE: 192.168.2.0/24
    Server f. BE: 192.168.13.0/24
    
    LÜ: "172.21.0.0/24,192.168.2.0/24,192.168.13.0/24"
    
    BE: "172.21.0.0/24,192.168.1.0/24,192.168.13.0/24"
    
    BÖ: "172.21.0.0/24,192.168.2.0/24,192.168.1.0/24"
    code
    

    OpenVPV Server Lü
    Jetzt

    0_1534057376192_Lü.png

    Vorherr

    0_1534057463626_Lü-vorh.png

    Routing BE

    0_1534057936788_routing_BE.png
    0_1534057968339_routing_be.png

    Gruß



  • Gebt mir bitte ein Tipp wenn ich es zu kompliziert mache und es auch einfacher geht bzw stabiler läuft.
    Ich kann es ja umstricken.

    Ich möchte nur das die Standorte BE, LÜ und BÖ sich mit RE verbinden und die LANs untereinander erreichbar sind.

    BÖ < - > RE
    LÜ < - > RE
    BE < - > RE

    BÖ < - > LÜ
    BE < - > LÜ

    schöne Grüße



  • Von BE nach RE komme ich wieder.
    Er hängt aber von BE nach LÜ weiterhin.

    Was mich stutzig macht ist, das ein tracert auf LÜ über die Fritzbox geht und auf RE nicht.

    0_1534064420374_tracert BE.png

    Für mich als Laie heißt das doch das die pfsense in BE nicht weiß was sie mit der IP 192.168.1.5 anfangen soll und schickt sie überall raus, oder ?

    Gruß



  • Hallo,

    das Ganze ist doch gar nicht so kompliziert. Du hast 3 VPN Verbindungen. An jedem VPN Endpunkt, egal ob Server oder Client sind unter "Entfernte Netzwerke" jene einzutragen, die über diesen VPN-Tunnel zu erreichen sind.

    Im Klartext noch einmal, am Standort RE hast du 3 Server, je einen für einen weiteren Standort, an dem je ein entferntes Netz ist. So sind laut deinem Plan diese entfernten Netzwerke in den Server-Konfigs einzutragen:
    Server für LÜ: 192.168.1.0/24
    Server für BE: 192.168.2.0/24
    Server für BÖ: 192.168.13.0/24

    Das war es auch schon am Standort RE.

    Dann gehst du auf den Standort LÜ und trägst in der Client Konfig diese bei entfernte Netzwerke ein:
    172.21.0.0/24,192.168.2.0/24,192.168.13.0/24
    Das kannst du so rein kopieren. Kein Leerzeichen zwischen den einzelnen Netzen, CIDR-Notation.

    Am Standort BE soll das Feld "entfernte Netzwerke" so aussehen:
    172.21.0.0/24,192.168.1.0/24

    Und auf BÖ:
    172.21.0.0/24,192.168.1.0/24

    Das sieht nun anders aus als vorhin. Zuvor bin ich davon ausgegangen, dass sich alle Standorte erreichen können sollen.



  • This post is deleted!


  • @viragomann

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


  • Moderator

    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 😃



  • @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


  • Moderator

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


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy