[SOLVED] OpenVPN Client Export - Benutzerdefinierter Name des Client Packages

viragomann

Damit heißen wohl auch CA-Zertifikate u. Key-Files gleich. Verstehe, das ist blöd.
Keine Ahnung, wie das zu ändern wäre.

Allerdings ist das Package ein selbstextrahierendes 7-zip Installationspaket. Du könntest es also vor der Weitergabe an die User mit dem 7-zip FM öffnen, die Files darin umbenennen und die Konfig anpassen.

Aber, andere Frage: Warum bekommt ein und derselbe User 2 VPNs für ein und dieselbe Firewall?? Macht doch überhaupt keinen Sinn.

reschi1

@viragomann said in OpenVPN Client Export - Benutzerdefinierter Name des Client Packages:

Allerdings ist das Package ein selbstextrahierendes 7-zip Installationspaket. Du könntest es also vor der Weitergabe an die User mit dem 7-zip FM öffnen, die Files darin umbenennen und die Konfig anpassen.

Ja, ich habe bereits einen Client neu gepackt. Das ist mir zuviel Gefrickel, im Falle von Änderungen an den Client Packages (bspw. neue Zertifikate). Es sind nämlich sechs OpenVPN-Server für drei Anwendungsfälle, d.h. sechs Packages.

Aber, andere Frage: Warum bekommt ein und derselbe User 2 VPNs für ein und dieselbe Firewall?

Redundanz. Wenn der eine ISP down ist, können die Benutzer über den anderen hereinkommen.

viragomann

@reschi1 said in OpenVPN Client Export - Benutzerdefinierter Name des Client Packages:

Redundanz. Wenn der eine ISP down ist, können die Benutzer über den anderen hereinkommen.

Ist ja nicht nötig, 2 VPN-Konfigs dafür zu verteilen. Das ist ja bereits in OpenVPN integriert.
Voraussetzung ist, dass beide Server dieselbe CA verwenden.

Dann kannst du in der Client-Konfig gleich beide Server angeben. Wähle dazu im Client Export Utility bei Remote Access Server den Server auf WAN1 aus, gehe zum Feld Additional configuration options und füge

remote <2. WAN IP od. Hostnamen> 443 tcp
server-poll-timeout 6

ein.

"server-poll-timeout" ist die Zeit, die gewartet wird, bis der Server antwortet, ehe es beim anderen versucht wird. Ich glaub, der Standard ist 10.
Hinter "remote" steht eben der 2. Server, Port und Protokoll.

Wenn du das exportierst, seht in der Client-Konfig eben eine zweite remote-Zeilen und die Zeile server-poll-timeout.

Das bringt noch einen schönen Komfort-Gewinn: Bricht eine WAN-Verbindung weg, wird automatisch zur anderen gewechselt, ohne dass irgendetwas aufpoppt.
Es wird allerdings nicht eine funktionierende Verbindung aufgegeben. D.h. eine Prio bspw. auf die erste gibt es da nicht. Solange die zweite funktioniert, bleibt der Client damit verbunden.

reschi1

Wow, das wäre ja zu schön um wahr zu sein, wenn das problemlos funktioniert.

Das teste ich morgen gleich mal.

Vielen Dank!

viragomann

Verwende ich an mehreren Installationen.

reschi1

Hmm, also ich habe nun zwei Test-OpenVPN-Server auf der pfSense aufgesetzt:

WAN #1: Client Package openvpn-mypfs-UDP4-1197-install-2.4.7-I603.exe (config + CA.crt + TLS.key)

dev tun
persist-tun
persist-key
cipher AES-256-CBC
ncp-ciphers AES-128-GCM
auth SHA512
tls-client
client
resolv-retry infinite
remote <pubIP WAN#1> 1197 udp
setenv opt block-outside-dns
auth-user-pass
ca mypfs-UDP4-1197-ca.crt
tls-auth mypfs-UDP4-1197-tls.key 1
remote-cert-tls server
mssfix 1440
auth-nocache
reneg-sec 0

WAN #2: Client Package openvpn-mypfs-UDP4-1197-install-2.4.7-I603.exe (config + CA.crt + TLS.key)

dev tun
persist-tun
persist-key
cipher AES-256-CBC
ncp-ciphers AES-128-GCM
auth SHA512
tls-client
client
resolv-retry infinite
remote <pubIP WAN#2> 1197 udp
setenv opt block-outside-dns
auth-user-pass
ca mypfs-UDP4-1197-ca.crt
tls-auth mypfs-UDP4-1197-tls.key 1
remote-cert-tls server
mssfix 1440
auth-nocache
reneg-sec 0

Der CA.crt ist bei beiden identisch.
Der TLS.key ist unterschiedlich.
Nacheinander Testverbindungen mit beiden Clients erfolgreich!

Zusammengesetzte Config:

dev tun
persist-tun
persist-key
cipher AES-256-CBC
ncp-ciphers AES-128-GCM
auth SHA512
tls-client
client
resolv-retry infinite
remote <pubIP WAN#1> 1197 udp
setenv opt block-outside-dns
auth-user-pass
ca mypfs-UDP4-1197-ca.crt
tls-auth mypfs-UDP4-1197-tls.key 1
remote-cert-tls server
mssfix 1440
auth-nocache
reneg-sec 0
remote <pubIP WAN#1> 1197 udp
server-poll-timeout 6

Testergebnis mit zusammengesetzter Config, wobei CA.crt und TLS.key des WAN#1 Clients im Config-Ordner liegen:

Initiale Verbindungsherstellung erfolgreich! Client bekommt IP vom WAN#1 OpenVPN-Server.
Deaktivierung des WAN#1 OpenVPN-Servers bei laufender Verbindung
Ergebnis: Kein Failover zum WAN#2 OpenVPN-Server
Trennen der Verbindung am Client, Neuverbinden am Client
Ergebnis: Keine Verbindungsherstellung möglich
TLS.key des WAN#2 Clients in den Config-Ordner kopieren (WAN#1 TLS.key wird überschrieben).
Verbindungsherstellung am Client erfolgreich! Client bekommt IP des WAN #2 OpenVPN-Servers.

Kombiniere: Bei deinem Setup sind keine TLS.keys im Spiel?

viragomann

@reschi1 said in OpenVPN Client Export - Benutzerdefinierter Name des Client Packages:

Kombiniere: Bei deinem Setup sind keine TLS.keys im Spiel?

Ist schon länger her, aber vermutlich habe ich auch gleiche TLS-Keys für beide Server.

Bei einer anderen Installation habe ich es aber völlig anders gelöst: Da läuft nur ein OpenVPN-Server für beide WANs, dieser lauscht auf localhost, und die beiden WAN Adressen habe ich auf localhost forwarded.

Diese Variante ist einfacher zu verwalten.
Bevor die Frage aufkommt, das Forwarden auf localhost bedeutet kein höheres Risiko, solange die Regel nur den Port weiterleitet, an dem der Server lauscht. Das wird generell so empfohlen.

reschi1

@viragomann said in OpenVPN Client Export - Benutzerdefinierter Name des Client Packages:

Ist schon länger her, aber vermutlich habe ich auch gleiche TLS-Keys für beide Server.

So war es wohl. Habe in der Serverkonfiguration den TLS-Key des WAN#2-OpenVPN-Servers mit dem Key des WAN#1-Servers überschrieben. Ergebnis: Funktioniert!

Vielen Dank!

JeGr

TLS Keys müssen gleich sein, sonst klappts nicht mit dem MultiWAN VPN ;)

Außerdem zum ursprünglichen Problem: Ja das Naming mag suboptimal sein. 2x EXE Dateien verteilen ist aber genauso Unfug ;) Wenn der Client einmal sauber installiert ist bringt das zweite Paket nur sinnlos einen Installer mit, den keiner braucht. Seit OpenVPN 2.4 kann jeder Benutzer bei sauber installiertem OpenVPN seine Konfigs selbst in %USERDATA%/OpenVPN/Config ablegen und die werden von der neuen OVPN GUI problemlos eingelesen und genutzt. Dafür dann mehrere EXE oder MSI Packages zu verteilen ist unnötig, da wärs einfacher einmal automatisiert überall den Client sauber installieren zu lassen und danach einfach die .ovpn Files zu verteilen. Und die Verbindung heißt bei mehreren OVPN Files auch immer wie der filename.ovpn. Einige unserer Kunden nutzen das für Szenarien, wo User eine Kombi-Konfig ausgerollt bekommen (also mit 2 remote Einträgen für Redundanz aber eine der beiden Leitungen wird bevorzugt) aber einige Leute gezielt die eine oder andere Leitung ansprechen wollen. Die bekommen dann einfach 2 Files ausgerollt à la

Verbindungsname (WAN1).ovpn
Verbindungsname (WAN2).ovpn

Meist haben die dann selbst trotzdem noch 2 Remote Einträge drin für Umschwenken von UDP auf TCP/443 in Hotels oder solchen Umgebungen mit kürzerem Timeout. Damit hat man dann ggf. sogar 4-in-1 Konfigs.

BTW: man kann mit dem Zusatzkeyword "remote-random" in der Client Konfiguration auch bei ca. 10 Usern und mehr eine schöne zufällige Verteilung auf beide Leitungen erreichen (wenn man keinen Favoriten definiert hat). Damit hat man dann ab ca. dem Dutzend Leuten eine halbwegs gleichverteile Nutzung der Leitung durch zufällige Einwahl auf 1 oder 2 :)

Sorry musste sein, hatte gerade erst einen pfSense-OpenVPN Vortrag gehalten ^^

reschi1

Vielen Dank @JeGr für die wertvollen Anmerkungen.