OpenSSL PtoP Verbindung über Shared KEy

[opnsensef8]

Hallo,

ich habe einen OpenSSL Server angelegt, auf den per shared key von außen verbunden wird. Ein Client (eine andere OPNsense) verbindet sich schon drauf. Jetzt würde ich gerne eine weitere OPNsense verbinden lassen. Geht das überhaupt? Die Pool IP ist bei beiden Clients die selbe...das sieht so aktuell nicht gut aus. Darum die Frage:


Standortvernetzung über OpenVPN mit shared key (da einfach zu konfigurieren auf der Clientseite) von mehreren Standorten aus auf den Server parallel einrichtbar?

[opnsensef8]

UPDATE:

Das was ich mit der PtoP Verbindung vorhabe scheint nicht wirklich so zu funktionieren. Darum die Frage: wie wird ein Client auf der OPNsense denn zu einem "RoadWarrior" Seerver verbunden bzw., wie ist der einzurichten?

Aufgabenstellung: viele OPNsense Firewalls verbinden sich auf eine zentrale Instanz, analog einem VPN Softwareclient. Die Unterscheidung wird dabei über den Usernamen/Passwort geregelt.

Den Server einzurichten ist dabei nicht das Problem, sondern die "Client-Seite" auf den externen OPNsense Instanzen: da hapert es gerade (CA/Zertifikate/Keys von wo nach wo...usw.)

[opnsensef8]

Hallo,

ist meine Idee nicht umsetzbar?

Ich versuche es nochmals zu beschreiben, für den Fall, dass meine vorherigen Versuche etwas zu verwirrend sind:

OPNsense SSL-VPN Server in der Zentrale. Dort wählen sich nun viele anderen OPNsense Firewalls "ein". IPsec kann leider nicht genutzt werden, da es ggf. private Subnetze mit NAT usw. zwischen den externen OPENsens Instanzen gaben kann. Auch ist die peer to peer Variante der OpenVPN Verbindung nicht ideal, da ich nur einen bestimmten Port zum Verbindungsaufbau verwenden kann..somit sollte das wie beim VPN Client über einen Port zum Server hin möglich sein.

Oder gibt es hier eine elegantere Lösung? Zerotier war von der Performance her zu schlecht.

[JeGr]

> Standortvernetzung über OpenVPN mit shared key (da einfach zu konfigurieren auf der Clientseite) von mehreren Standorten aus auf den Server parallel einrichtbar?

Shared Key Verbindungen können da PtoP nur zwischen 2 Geräten funktionieren. Das ist OpenVPN Basic. Wenn du mit einem OpenVPN Service (ein laufender Service) 2 oder mehr Geräte in Tunnelart anbinden möchtest, geht das nur mit einem SSL/TLS Typ Server. Hier müsste dann bei mehreren Tunneln entweder alle entfernten Netze unter "remote networks" einzeln aufgeführt werden oder wenn diese sinnvoll vergeben sind eine entsprechend höhere CIDR Maske (Beispiel entfernte Netze sind 192.168.101.0/24 und .102.0/24 dann könnte 192.168/16 angeführt werden). Anschließend müsste dann bei den CSOs ggf. noch genauere Netze reingepackt werden, damit klar ist, welches entfernte Netz über welche Verbindung angesprochen wird.

Einfacher und ggf. für den weiteren Einsatz sinnvoller ist es, jede Site2Site Verbindung mit eigenem Tunnel zu konfigurieren.

> Auch ist die peer to peer Variante der OpenVPN Verbindung nicht ideal, da ich nur einen bestimmten Port zum Verbindungsaufbau verwenden kann

Das versteht leider niemand. Was möchtest du damit sagen? P2P nutzt genauso wie Client Einwahl immer nur genau einen Port - als default udp/1194. Die Art und Weise der Konfiguration ist völlig egal, OpenVPN per se arbeitet nur mit diesem einen Port. Ich sehe da also überhaupt kein Problem? Ich glaube du wirfst hier wild einige verschiedene Socken durcheinander

> Oder gibt es hier eine elegantere Lösung? Zerotier war von der Performance her zu schlecht.

Bei mehreren Firmen genauso im Einsatz. Eine Verbindung pro Gegenstelle. Ja man muss dann in der Zentrale für jede Außenstelle eine neue VPN Serverinstanz erstellen. Da OpenVPN aber in 2.x noch nicht Multicore fähig ist und somit single-core-bound ist, macht es alleine aus CPU/Ressourcensicht schonmal Sinn, die Last ggf. auf mehr CPU Kerne zu verteilen. Zudem ist es somit einfacher gezielt einen einzigen Tunnel zu debuggen und neuzustarten. Die Konfiguration auf der Gegenseite (also Außenstelle / Client) ist dabei herrlich statisch, so dass man diese bis auf lokales Netz und Transfernetz Angabe annähernd 1:1 übernehmen/exportieren kann und damit einfach zu deployen/kopieren ist.

Gruß

[opnsensef8]

Hallo,

vielen Dank für die erste Antwort.

Um hier nicht noch mehr durcheinander zu werfen die Anforderung:

Viele OPNsense-Standorte müssen untereinander vernetzt werden. Dabei müssen Daten nur zu einer zentralen OPNsense übermittelt werden können.

Für mich als Neuling wäre es super, wenn ich eine Art Tutorial oder kleines HowTo bekommen könnte. Wie richtige ich die Zentrale ein, wie die "Aussenstellen". OpenVPN wäre hierbei die Voraussetzung, da bedingt durch NAT in den Außenstellen kein IPsec Tunnel anzuwenden ist.

Zentrale OPNsense: was muss wie eingerichtet werden
Außenstellen OPNsense: wie ist hier der OpenVPN Teil einzurichten.
->Tolle wäre eine einfache und gut kopierbare Außenstellenkonfiguration...

Vielen Dank vorab für Tips!

[JeGr]

> da bedingt durch NAT in den Außenstellen kein IPsec Tunnel anzuwenden ist.

Das stimmt ja m.W. nur zum Teil (dafür gibts bei IPSec ja NAT-T) aber ich würde an der Stelle sehr wahrscheinlich auch OVPN bevorzugen für späteren Ausbau.

Wenn nur Außenstellen->Zentrale gesprochen wird, sollte sich der Aufwand auch stark in Grenzen halten. Schwieriger aber keinesfalls unmöglich wäre dann A1->Zentrale->A2 also Kommunikation über die Zentrale hinweg in andere Außenstellen oder Außenstellen miteinander. Da muss man dann abwägen ob es sich lohnt über die Zentrale zu reden oder ob man die direkt verbindet.

Bevor ich da ggf. ein paar Stichpunkte zum Einrichten schreiben kann: Wie sind denn Zentrale und Außenstellen IP-technisch aufgebaut? Welche Netze wo etc.? Oder kannst du da tatsächlich noch was dran ändern/anpassen? Ist das fest?

[opnsensef8]

Hallo,

das Setup ist denkbar einfach:

-Zentrale OPNsense mit zentrale.domain.de statisch mit einem privaten Backbone-Subnetz (192.168.33.0/24)
-Die Aussenstandort OPNsense (aktuell "nur" 5 an der Zahl) nutzen billig-Pappenheimer DSL Anschlüsse mit DHCP an den dort vorhandenen Routern im privaten Adressbereich. Adressbereiche Subnetze Standort: 192.168.40.0/24 bis 192.168.44.0/24)

Super hilfreich wäre für mich eine Beispielkonfiguration Serverseite-Client(bzw. Außenstandort)seite als Howto/Screenshot Doku.

Ich glaube, dass ich aktuell noch nicht entscheiden kann (mangels gewusst wie), wie ich den Zentralen Knoten aufsetze respektive die Außenstellen. Dabei kommt es mir nicht auf Firewallsettings an, sondern ganz speziell auf die Einrichtung des SSL VPN Teils.

UPDATE: ich habe nun einen Peer to Peer Tunnel eingerichtet. Der läuft auf Anhieb. Nun habe ich damit aber ein Problem: Webseitenzugriffe (z.B. Auf Webinterfaces der Geräte auf der Gegenseite klappen einwandfrei. Sobald aber Daten transferiert werden, brechen die Transfers ab. SMB/HTTP Upload. Egal mit welchem Protokoll. Größere Datenmengen können nicht überrtagen werden. Lokale Zugriff auf der Zentrale (OPNsens auf die Server dort) laufen einwandfrei. Auch am "Außenstandort" ist das LAN und die Performance gut. Aber alles was über den Tunnel geht: miserabel bis Abbruch. Manchmal startet ein Filetransfer, manchmal gar nicht. TCP WindowSize?

19:36:38.067697 IP LANZENTRALE.61243 > LANAUSSENSTELLE.microsoft-ds: Flags [P.], seq 179:345, ack 207, win 1026, length 166 SMB-over-TCP packet:(raw data or continuation?)

[opnsensef8]

Hallo,

habe nun nochmals ein paar Kreuztest gemacht. Dazu habe ich auf den jeweiligen OPNsense Firewalls (mittlerweile 3 externe Standorte und die Zentrale) jeweils einen OpenVPN Server für die Clienteinwahl konfiguriert. An alle Standorte vom Client aus super Übertragungsraten. Sobald aber wieder zwischen den Standorten übertragen wird über den peer to peer VPN Tunnel: Abbrüche.

Also muss das Problem OpenVPN PtoP immanent sein.

Noch ein Dump von der Zentrale aus. Beobachtet wir ein Windows Explorer, der auf eine Freigabe in der Aussenstelle zugreifen will ggf. kann mir hier jemand Tips dazu geben. Interface ovpnc1

16:17:32.241552 IP ZENTRALE.52729 > HOSTAUSSENSTELLE.445: Flags [P.], seq 1:179, ack 1, win 1026, length 178 SMB-over-TCP packet:(raw data or continuation?)

16:17:32.242542 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52729: Flags [.], ack 179, win 123, length 0
16:17:32.269079 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52729: Flags [P.], seq 1:207, ack 179, win 123, length 206 SMB-over-TCP packet:(raw data or continuation?)

16:17:32.269920 IP ZENTRALE.52729 > HOSTAUSSENSTELLE.445: Flags [P.], seq 179:345, ack 207, win 1026, length 166 SMB-over-TCP packet:(raw data or continuation?)

16:17:32.272748 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52729: Flags [P.], seq 207:476, ack 345, win 131, length 269 SMB-over-TCP packet:(raw data or continuation?)

16:17:32.273190 IP ZENTRALE.52729 > HOSTAUSSENSTELLE.445: Flags [P.], seq 345:906, ack 476, win 1025, length 561 SMB-over-TCP packet:(raw data or continuation?)

16:17:32.283680 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52729: Flags [P.], seq 476:553, ack 906, win 140, length 77 SMB-over-TCP packet:(raw data or continuation?)

16:17:32.336655 IP ZENTRALE.52729 > HOSTAUSSENSTELLE.445: Flags [.], ack 553, win 1024, length 0
16:17:32.453384 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52707: Flags [F.], seq 1, ack 1, win 140, length 0
16:17:32.665952 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52707: Flags [F.], seq 1, ack 1, win 140, length 0
16:17:32.742814 IP ZENTRALE.986 > HOSTAUSSENSTELLE.111: Flags , seq 2801388187, win 8192, options [mss 1100,nop,wscale 8,nop,nop,sackOK], length 0
16:17:32.744237 IP HOSTAUSSENSTELLE.111 > ZENTRALE.986: Flags [R.], seq 0, ack 1, win 0, length 0
16:17:33.095013 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52707: Flags [F.], seq 1, ack 1, win 140, length 0
16:17:33.258400 IP ZENTRALE.986 > HOSTAUSSENSTELLE.111: Flags , seq 2801388187, win 8192, options [mss 1100,nop,nop,sackOK], length 0
16:17:33.259870 IP HOSTAUSSENSTELLE.111 > ZENTRALE.986: Flags [R.], seq 0, ack 1, win 0, length 0
16:17:33.260101 IP ZENTRALE.927 > HOSTAUSSENSTELLE.111: UDP, length 56
16:17:33.261019 IP HOSTAUSSENSTELLE > ZENTRALE: ICMP HOSTAUSSENSTELLE udp port 111 unreachable, length 92
16:17:33.952091 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52707: Flags [F.], seq 1, ack 1, win 140, length 0
16:17:34.070922 IP ZENTRALE.927 > HOSTAUSSENSTELLE.111: UDP, length 56
16:17:34.072397 IP HOSTAUSSENSTELLE > ZENTRALE: ICMP HOSTAUSSENSTELLE udp port 111 unreachable, length 92
16:17:35.667916 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52707: Flags [F.], seq 1, ack 1, win 140, length 0
16:17:35.680292 IP ZENTRALE.948 > HOSTAUSSENSTELLE.111: Flags [SEW], seq 921973020, win 8192, options [mss 1100,nop,wscale 8,nop,nop,sackOK], length 0
16:17:35.681522 IP HOSTAUSSENSTELLE.111 > ZENTRALE.948: Flags [R.], seq 0, ack 921973021, win 0, length 0
16:17:36.196003 IP ZENTRALE.948 > HOSTAUSSENSTELLE.111: Flags , seq 921973020, win 8192, options [mss 1100,nop,wscale 8,nop,nop,sackOK], length 0
16:17:36.197592 IP HOSTAUSSENSTELLE.111 > ZENTRALE.948: Flags [R.], seq 0, ack 1, win 0, length 0
16:17:36.711463 IP ZENTRALE.948 > HOSTAUSSENSTELLE.111: Flags , seq 921973020, win 8192, options [mss 1100,nop,nop,sackOK], length 0
16:17:36.713077 IP HOSTAUSSENSTELLE.111 > ZENTRALE.948: Flags [R.], seq 0, ack 1, win 0, length 0
16:17:36.713344 IP ZENTRALE.927 > HOSTAUSSENSTELLE.111: UDP, length 56
16:17:36.714297 IP HOSTAUSSENSTELLE > ZENTRALE: ICMP HOSTAUSSENSTELLE udp port 111 unreachable, length 92
16:17:37.524031 IP ZENTRALE.927 > HOSTAUSSENSTELLE.111: UDP, length 56
16:17:37.525542 IP HOSTAUSSENSTELLE > ZENTRALE: ICMP HOSTAUSSENSTELLE udp port 111 unreachable, length 92
16:17:39.104005 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52707: Flags [F.], seq 1, ack 1, win 140, length 0