OPENVPN und mehrere Standorte

[achim55]

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

[Gladius]

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

[viragomann]

@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

[Gladius]

@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

[achim55]

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

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

Und so habe ich die IPs eingetragen.
LÜ

BE

BÖ

und die Interfaces sind auch online

Habe ich da noch etwas übersehen ?

schöne Grüße

[Gladius]

Ein Denkanstoß

Damit bin hier raus.

LG

[viragomann]

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

[achim55]

@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

von LÜ nach BE

von RE nach LÜ

von RE nach BE

[viragomann]

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.

[achim55]

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

RE nach BE

RE nach LÜ

BE nach LÜ

BE nach RE

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

[viragomann]

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

[achim55]

@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

Vorherr

Routing BE

Gruß

[achim55]

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

[achim55]

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.

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ß

[viragomann]

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.

[achim55]

This post is deleted!

[achim55]

@viragomann

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

[JeGr]

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

[Gladius]

@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

[JeGr]

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