OpenVPN für Clients
-
@viragomann said in OpenVPN für Clients:
@jegr said in OpenVPN für Clients:
Man kann das im Advanced Block des Client Export Tools reinschreiben und speichern.
Gute Idee. Da genügt es dann aber nur den zusäztlichen Host reinzuschreiben, oder?Genau so sollte es sein. Wenn es gegen eine dynamische IP geht, dann ggf. oben noch das Feld manuell mit dem DynDNS Domainnamen bespaßen damit der erste remote Eintrag auch sauber passt.
Genauso übrigens auch die Möglichkeit für "Lastverteilung" wenn man 2 halbwegs gleiche Leitungen hat. Einfach den Clients in die Konfiguration beide Endpunkte für VPN auf Leitung 1 und 2 eintragen und zusätzlich bei Wunsch noch nach dem 2. Remote Statement ein remote-random mit reinpacken, schon wird zufällig mal mit Line1 oder 2 die Verbindung aufgebaut. Bei Abbruch von einer sollten diese Clients dann durch beide Einträge automatisch auf der noch verbliebenen sammeln.
-
@jegr said in OpenVPN für Clients:
Ich verstehe da ganz ehrlich den Aufriss mit stunnel nicht so ganz
Ich hole mal etwas weiter aus. Grundgedanke war die Nutzung eines OpenVPN-Tunnels auch in einem Roadwarrior
Szenarium in einer Client-Umgebung mit Filterung gängiger OpenVPN-Ports. Für Site2Site Szenarien würde ich das
erst einmal nicht in Betracht ziehen.Nun, der TCP-Port 443 bot sich für den Tunnel OpenVPN über SSL an. Er wird wohl kaum geblockt werden.
HAProxy, gegebenenfalls stunnel, ist ja als Paket bei pfSense vorhanden und auch für Clients verfügbar.Frisch ans Werk und den Tunnel gebaut. Ging nicht auf Anhieb, mußte erst im Netz Informationen sammeln.
Er läuft aber ohne zu mucken auf meiner etwas großzügiger dimensionierten Hardware.Okay, wie schon gesagt: viele Wege führen nach Rom.
-
Nun, der TCP-Port 443 bot sich für den Tunnel OpenVPN über SSL an. Er wird wohl kaum geblockt werden.
HAProxy, gegebenenfalls stunnel, ist ja als Paket bei pfSense vorhanden und auch für Clients verfügbar.OK da kann ich dir folgen, aber was mich dann rauswirft ;)
Warum nicht simpel OpenVPN selbst via tcp/443 betreiben mit den transparent Optionen und Möglichkeit das sogar an einen Webservice durchzureichen (quasi als Alibi *g) und damit die Komplexität von HAproxy und stunnel zu sparen? Das ist meine eigentliche Frage gewesen :) Dass man tcp/443 ggf. vorzieht wenn udp/1194 nicht funktioniert kann ich verstehen. Kein Problem. Nur warum das komplexe Drumherum, wenn es doch OVPN selbst bietet? Denn du nutzt ja keine zusätzlichen Optionen - zumindest habe ich nichts rausgelesen - was jetzt explizit stunnel oder haproxy betrifft (sowas wie clientseitiges Zertifikat bei SSL für Auth gg. haproxy o.ä. - was eh doppelt gemoppelt wäre, da man sich dann nochmal mit user/pw/cert bei OVPN anmeldet)
-
@jegr said in OpenVPN für Clients:
Nur warum das komplexe Drumherum, wenn es doch OVPN selbst bietet?
Ich habe meine Entscheidung OpenVPN über SSL zu tunneln nicht in Unkenntnis anderer Möglichkeiten getroffen.
Nein, das war eine ganz gezielte Aktion in meinem Umfeld und ich würde es wieder so machen, selbst wenn ich
weltweit der Einzige wäre.Die Lösung funktioniert zufriedenstellend. Falls es mal Probleme damit geben sollte, werde ich nach
Alternativen suchen. Nach meiner Meinung bringt eine Fortführung der Diskussion über meine Motive
keine brauchbaren Ergebnisse. Jeder sollte nach seinen Kenntnissen, Vorlieben, was auch immer,
das im Thema angesprochene Problem angehen.LG
-
@gladius said in OpenVPN für Clients:
Nein, das war eine ganz gezielte Aktion in meinem Umfeld und ich würde es wieder so machen, selbst wenn ich
weltweit der Einzige wäre.Das habe ich ja nicht in Abrede gestellt, sondern frage mich nur, was der Vorteil deiner Methodik gegenüber dem nativen OpenVPN via TCP ist?
Vielleicht hast du meine Nachfrage mißverstanden, aber es geht mir da wirklich eher darum, was deine Intention ist bzw. wo du denkst, dass deine Variante ggf. besser funktioniert? Man lernt ja gerne was dazu, darum versuche ich da überhaupt nicht dagegen zu argumentieren, sondern hinterfrage lediglich den Vorteil. Wenn du sagst, es gibt da keinen großen Vorteil oder das gibt sich nix, du wolltest es aber so bauen - auch gut -> basteln bringt immer was, und sei es nur, dass man was dazu gelernt hat. Aber genau deshalb frage ich nach - berufliche Neugier
Gruß Jens
-
@jegr said in OpenVPN für Clients:
sondern frage mich nur, was der Vorteil deiner Methodik gegenüber dem nativen OpenVPN via TCP ist?
Ich kann keine Vorteile erkennen. Die Anforderungen an die Hardware sind zwar für mich beherrschbar, aber höher
als bei der hier vorgeschlagenen Lösung mit zwei Instanzen. Weiterhin muß man einmalig serverseitig mehr
installieren, konfigurieren und ein Anfänger hat mit OpenVPN wohl erst einmal wichtigere Aufgaben zu lösen.Damit sind wir doch wieder bei den Motiven gelandet. Was hat mich zu dieser sehr speziellen Lösung geführt?
Der Reiz sich abseits von bekannten Wegen eine Lösung zu erarbeiten sage ich mal.
Ich bin so ein Typ, der auch nicht unbedingt Hardware von der Stange kauft, sondern Spaß am "Basteln" hat.
Liegt es in den Genen?LG
Nachtrag:
pfSense nutze ich seit vielen Jahren. Anfangs hatte ich eine ALIX-Kiste. An die damalige Version
von pfSense kann ich mich gar nicht mehr erinnern. Da müßte ich nachgraben. -
Uh die damalige Version hab ich noch gut vor Augen... bisschen gruselig und nicht anders als ein Re-Skin von Monowall damals.
Manchmal ein bisschen gruselig aber hey... für 2008 war das schon echt gut :) Und das mit dem Basteln kenne ich, aber man wird irgendwann auch älter und kommt in die Kategorie "muss einfach ruhig laufen" ;)
Die Anforderungen an die Hardware sind zwar für mich beherrschbar, aber höher
als bei der hier vorgeschlagenen Lösung mit zwei Instanzen.Kurze Frage dazu: Deine Lösung läuft aber (nur) mit TCP? Oder mit udp & tcp?
-
@jegr said in OpenVPN für Clients:
Kurze Frage dazu: Deine Lösung läuft aber (nur) mit TCP? Oder mit udp & tcp?
Läuft nur mit OpenVPN/TCP. Clientseitig verwende ich ja OpenVPN in Kombination mit stunnel und
UDP-Pakete von OpenVPN will stunnel nicht haben. So war es als ich die Lösung getestet habe.
Ich bin dann bei OPenVPN/TCP geblieben und habe nicht weiter über UDP nachgedacht. -
Dann danke für die Ausführung :) Immer schön verschiedene Ansätze zu lesen. Auch wenn ich (rein subjektiv) denke, dass es für einen Anfänger an der Stelle einfacher ist, sich mit dem Assistenten dann ggf. einen OVPN mit tcp/443 einrichten zu lassen, hat die Lösung ja durchaus ihren ganz eigenen Charme :)
Allerdings sollte man auch nicht unerwähnt lassen, dass es durchaus schon Gründe für stunnel gab (allerdings dann ggf OpenVPN und UDP innendrin für Performance) um bspw. strenge IPS o.ä. auszuhebeln, die VPNs blocken. Trotz der neuen Crypto Settings in OpenVPN 2.4 gibts da wohl durchaus noch Systeme die das VPN blocken können.
-
Eine kurze Ergänzung zu meiner Lösung.
In einer weniger restriktiven Umgebung bzgl. Blockierung von OpenVPN kann clientseitig auf stunnel und
serverseitig auf HAProxy beim Aufbau des Tunnels verzichtet werde, denn OpenVPN serverseitig
verbindet ja auf einem TCP-Port.Mit anderen Worten:
Der Weg über stunnel kann clientseitig in Abhängigkeit von der jeweiligen Umgebung genutzt werden.
Zwingend erforderlich ist er nicht. -
Hallo zusammen,
ich habe nun eine zweite OpenVPN Instanz erstellt. Die Einstellungen sowie der TSL Key sind der gleiche. Einzigster unterschied das Protokoll habe ich auf TCP und Port 443 umgestellt.
In meiner Client Konfig habe ich den Eintrag hinzugefügt. Wenn ich mich per VPN Einwähle kommt die Passwortabfrage und danach kommt immer:
Sat Aug 11 12:43:51 2018 Connection reset, restarting [0]
Sat Aug 11 12:43:51 2018 SIGUSR1[soft,connection-reset] received, process restartingWenn ich per UDP über den Port 1194 einwähle dann geht es nach wie vor. Muss ich sonst etwas beachten?
-
Du musst natürlich noch den TCP Port auf der Sense freigeben.
