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



  • Hallo Forum!

    Wenn ich ein OpenVPN Windows Client Package exportiere, wird vom pfSense-System folgende Namenskonvention gewählt:

    openvpn-<NameDesPfSenseHosts>-<Protokoll><IPTyp>-<Port>-install-2.4.7-I603.exe

    Beispiel:

    • Der pfSense Hostname ist mypfs
    • Das konfigurierte OpenVPN-Protokoll ist UDP
    • Der IP-Typ ist: IPv4
    • Der konfigurierte Port ist 1195

    Das Client Package heißt dann so:

    openvpn-mypfs-UDP4-1195-install-2.4.7-I603.exe

    Ich möchte, dass das Paket mit einem benutzerdefinierten Namen ausgegeben wird.

    Kann dies irgendwo konfiguriert werden, oder wo in den Tiefen der Konfigurationsdateien der pfSense kann ich das anpassen?

    Besten Dank!

    Gruß,
    reschi



  • Hallo!

    Warum?
    Eine Funktion zum Umbenennen bietet jeder Dateimanager und jede Kommandozeile.

    Wenn du das anders haben möchtest, müsstest du wohl an den Code des Packages ran, und dieser würde bei einem Update wieder überschrieben werden.
    Das lohnt wohl kaum.

    Grüße



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

    Warum?

    Weil ich mehrere OpenVPN-Server auf dem Gateway habe.

    Wenn ich OpenVPN-Server #1 auf dem WAN-Interface des ISPs #1 unter TCP 443 bereitstelle, und OpenVPN-Server #2 auf dem WAN-Interface des ISPs #2 und beide auf TCP 443 konfiguriert sind, werden beide Client Packages mit dem gleichen Namen ausgegeben.

    Installiert der OpenVPN-Benutzer nacheinander beide Packages auf seinem Rechner, überschreibt die Config des zweiten Clients die des erstinstallierten.

    Wenn ich unterschiedliche Namen möchte, müssen nach dem Export die Config-Datei und die darin referenzierten Key- und Zertifikatsnamen ebenfalls umbenannt werden. Natürlich entsprechend auch die Namen der Key- und Zertifikatsdateien.

    Das kann ich den Benutzern nicht zumuten - Sales, Marketing, Verwaltung.... die sind mit sowas überfordert.



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



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



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



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

    Das teste ich morgen gleich mal.

    Vielen Dank!



  • Verwende ich an mehreren Installationen.



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

    1. 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
    
    1. 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?



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



  • @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!


  • LAYER 8 Moderator

    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 ^^



  • Vielen Dank @JeGr für die wertvollen Anmerkungen.


Log in to reply