OPENVPN und mehrere Standorte

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