Andy's Blog

OpenVPN-Server unter Windows einrichten – Erste überarbeitete Fassung

19. Januar 2022 / / 44 Kommentare

Der Beitrag OpenVPN-Server unter Windows einrichten gehört trotz seines mehrjährigen Alters mit zu den beliebtesten Veröffentlichungen in diesem Blog. Im Laufe der Zeit hat sich so manches verändert, daher wird es Zeit für eine überarbeitete Fassung.

Gleich Vorweg und Wichtig: Die Nutzung von Windows (Server) als VPN-Server empfehlen wir zudem ausdrücklich nicht!

Auf verschiedenen Wegen werde ich nahezu regelmäßig danach gefragt, ob es ein Update zu diesem Thema gibt oder geben wird. Zuletzt hatte ich dieses im November 2021 via Kommentar noch ausgeschlossen, aber was soll man sagen: Dinge ändern sich und so ergab es sich nun, gerade einmal gut zwei Monate später, das ich dieses Thema doch aufgreifen muss.

Grundsätzlich sei erwähnt, das man einen OpenVPN-Server (in der Community-Ausgabe) unter Windows betreiben kann, ich empfehle dennoch eher richtige VPN-Firewall-Router, wie z.B. pfSense, OPNsense oder Securepoint UTM,  die eine ordentliche Implementierung und insgesamt eine einfachere sowie weitreichendere Handhabe bei der Konfiguration und mehr Funktionen aufweisen.

Änderungen gegenüber des ersten Beitrags

Wie eingangs bereits erwähnt haben sich ein paar Dinge in der Zwischenzeit geändert, da wäre beispielsweise das easy-rsa zwischenzeitlich nicht mehr im Bundle enthalten war. Ferner haben sich Konfigurationsoptionen sowie die Verschlüsselung und Pfade geändert.

Die aktuelle Version von easy-rsa lässt sich wohl auch nicht ganz so einfach (unter Windows) nutzen wie in der Vergangenheit. Um es insgesamt dem gemeinen Windows-Administrator einfacher zu machen, wird in dieser Fassung die Zertifikatverwaltung mittels XCA durchgeführt. Dies bietet zudem einen einfacheren Überblick über die ausgestellten Zertifikate und deren Status.

Zwecks Benutzeranmeldung wurde zudem im früheren Beitrag ein Skript verwendet, das aus einer mittlerweile nicht mehr verfügbaren Quelle stammt. Um die Verständlichkeit dieses Abschnitts etwas zu erhöhen, wurde dieses Skript ebenfalls überarbeitet und vereinfacht.

Die folgenden Schritte wurden auf einem Windows Server 2012 R2 durchgeführt, sie sollten allerdings auch unter neueren Windows-Versionen funktionieren. Die OpenVPN-Konfiguration besteht in der Hauptsache aus den beim Setup mitgelieferten Beispielen, die nur wenig angepasst werden. Es handelt sich im ein Roadwarrior-Setup, es geht also um VPN-Verbindungen beispielsweise von Außendienst-Mitarbeitern zur Firma. Nicht behandelt wird die Möglichkeit einer Standortvernetzung (Site-to-Site, s2s). Grundlegende Kenntnisse in Netzwerken, Routing und OpenVPN sowie Zertifiakten sind für die nachfolgende Anleitung durchaus zu empfehlen.

Soviel zum Vorwort, schreiten wir nun zur Tat.

Zertifikatsverwaltung mit XCA einrichten

Die aktuelle Version von XCA herunterladen und entpacken (ZIP, portable) oder installieren (MSI). Für diesen Beitrag kommt “xca-portable-2.4.0.zip” zum Einsatz.

Im ersten Schritt muss XCA gestartet und mittels

Datei - Neue Datenbank

eine neue Datenbank erstellt werden. Beim Anlegen einer neuen Datenbank wird man nach einem Kennwort gefragt, dieses sollte sicher gewählt und die entsprechende Datenbank-Datei zudem sicher aufbewahrt werden!

Tipp: Sichere Kennwörter erstellen und deren Verwaltung kann mit KeePass realisiert werden.

Zertifizierungsstelle/CA erstellen

Die Zertifizierungsstelle (engl. certificate authority) ist für das Ausstellen der Zertifikate und für das Vertrauen in diese verantwortlich. Damit eine CA überhaupt Zertifikate ausstellen und sozusagen Unterschreiben kann, ist zunächst das CA-Zertifikat samt privaten Schlüssel notwendig.

Zertifikatvorlagen erstellen

Damit man beim Ausstellen der nachfolgenden Zertifikate nicht immer alles von vorne eingeben muss und damit die jeweiligen Zertifikate für den richtigen Zweck ausgestellt werden, ist das Einrichten der Vorlagen relevant.

  • Auf der Registerkarte “Vorlagen” die Schaltfläche “Neue Vorlage” anklicken” und “[default] CA” auswählen.
  • Die notwendigen Felder (siehe Screenshot) entsprechend angepasst ausfüllen, dabei das Feld “commonName” leer lassen.

  • Ggf. auf der Registerkarte “Erweiterungen” die Laufzeit anpassen.
    Tipp: An dieser Stelle den Haken bei “Mitternacht” setzen, das sieht i.d.R. besser aus und man kann die Ablaufzeiträume besser überschauen.

Die Schritte für “[default] tls-server” (für den OpenVPN-Server) und “[default] tls-client” (für die Roadwarrior) wiederholen. Auch bei diesen ggf. die Laufzeit (die Vorgabe ist ein Jahr) ändern.

Letztlich müssen drei Vorlagen vorhanden sein:

CA-Zertifikat erstellen

  • In XCA auf der Registerkarte “Zertifikate” die Schaltfläche “Neues Zertifikat” anklicken.
  • Auf der Registerkarte “Herkunft” unter “Vorlage für das neue Zertifikat” die zuvor erstellte CA-Vorlage auswählen und auf “Alles übernehmen” klicken.
  • Zur Registerkarte “Inhaber” wechseln und im Feld “Interner Name” und “commonName” z.B. OpenVPN-CA eintragen.
  • Auf “Erstelle einen neuen Schlüssel” sowie anschließend auf “Erstellen” klicken:

  • Abschließend noch auf “OK” klicken, somit ist die grundlegende CA erstellt.

Server-Zertifikat erstellen

  • Auf der Registerkarte “Zertifikate” die Schaltfläche “Neues Zertifikat” anklicken.
  • Auf der Registerkarte “Herkunft” bei “Verwende dieses Zertifikat zum Unterschreiben” das zuvor erstellte CA-Zertifikat auswählen und unter “Vorlage für das neue Zertifikat” die zuvor erstellte Server-Vorlage auswählen sowie auf “Alles übernehmen” klicken.

  • Zur Registerkarte “Inhaber” wechseln und im Feld “Interner Name” und “commonName” z.B. OpenVPN-Server eintragen.
  • Auf “Erstelle einen neuen Schlüssel” sowie anschließend auf “Erstellen” klicken.

Client-Zertifikat(e) erstellen

Für jede VPN-Benutzer muss ein Zertifikat ausgestellt werden, die Schritte entsprechen denen wie für den OpenVPN-Server mit den Unterschieden, das die Client-Vorlage und bei “Interner Namen” sowie “commonName” dann beispielsweise das Schema

OpenVPN-Benutzer

verwendet werden kann.

CRL/Zertifikatsperrliste erstellen und exportieren

Eine Zertifikatsperrliste (engl. certificate revocation list, CRL) wird dringend empfohlen, um etwaige abhanden gekommene Zertifikate widerrufen, also sozusagen sperren zu können. Als Beispiel kann ein verloren gegangenes Notebook oder Smartphone dienen, man möchte sicher nicht, das der Finder sich ggf. einfach so mit dem VPN verbinden kann.

  • In XCA zur Registerkarte “Sperrlisten” wechseln.
  • Auf “Neue Sperrliste” klicken.
  • Eine Gültigkeitsdauer festlegen (Die Vorgabe sind 30 Tage).
  • Sobald die Sperrliste erstellt wurde diese mit einem Klick auf “Export” als “crl.pem” exportieren.

Bitte das Beitrags-Update (s.u.) vom 24.02.2022 zur CRL beachten!

Zertifikate exportieren

Damit die Zertifikate mit OpenVPN genutzt werden können, müssen diese im richtigen Format exportiert werden. Von der CA an sich wird nur das Zertifikat ohne den privaten Schlüssel benötigt! Vom Server als auch den Clients wird jeweils das Zertifikat mit Schlüssel exportiert.

  • Auf der Registerkarte “Zertifikate” das gewünschte Zertifikat auswählen und auf “Export” klicken.
  • Das CA-, Server- und die Client-Zertifikate im Format “PEM (*.crt)” als “ca.crt”, “server.crt” und “client.crt” exportieren.
  • Auf der Registerkarte “Private Schlüssel” nur die Schlüssel für das Server- und die Client-Zertifikate als “PEM privat (*.pem)” mit dem Dateinamen “server.key” und “client.key” exportieren.

Tipp: Klickt man ein Zertifikat oder den privaten Schlüssel mit der rechten Maustaste an, kann aus dem Untermenü “Export” beispielsweise dieses direkt in die Zwischenablage exportiert und von dort aus eine Datei, Notepad, usw. kopiert werden.

Weiteres

Es wird noch der Diffie Hellman (DH) Parameter benötigt:

  • Unter “Extra – DH Parameter erstellen” anklicken, als Wert “2048” eingeben und diese als “dh2048.pem” speichern.

Bemerkung: Sofern OpenVPN mit OpenSSL installiert wurde, kann der Parameter auch mit

openssl dhparam -out dh2048.pem 2048

erstellt werden.

OpenVPN-Server installieren und einrichten

Die aktuelle Ausgabe von OpenVPN (Community) herunterladen und angepasst, gemeint ist nach einem Klick auf “Customize” einschließlich “OpenVPN Service” installieren. Zu diesem Zeitpunkt ist das Version 2.5.5 vom 15. Dezember 2021.

Eine Eingabeaufforderung mit erhöhten Rechten öffnen und in den Ordner

C:\Program Files\OpenVPN\bin

wechseln. Als Vorbereitung für tls-auth folgenden Befehl ausführen:

openvpn --genkey tls-auth ta.key

Soweit sind nun alle Voraussetzungen erfüllt. Im nächsten Schritt geht es an die Konfiguration, als Basis dient das Beispiel unter

C:\Program Files\OpenVPN\sample-config\server.ovpn

Diese funktioniert nahezu Out-of-the-Box, allein schon mit den Zertifikaten kann man sich bereits anmelden. Es reicht also aus diese Datei in den Ordner

C:\Program Files\OpenVPN\config-auto

zu kopieren und den Dienst

OpenVPNService

neu starten. An gleicher Stelle müssen (vor dem Dienst-Neustart) die Dateien

ca.crt
server.crt
server.key
dh2048.pem
ta.key

kopiert bzw. eingefügt werden.

Folgende Änderungen in der Konfigurationsdatei gegenüber dem Original durchführen:

topology subnet
push "route 192.168.1.0 255.255.255.0" <- Hier muss das eigene Netz eingetragen werden
crl-verify crl.pem

Die folgenden Zeilen sind nur notwendig, wenn man Namensauflösung (DNS) via VPN verwenden möchte:

push "dhcp-option DNS 192.168.1.10" <- Hier den eigenen DNS-Server eintragen
push "dhcp-option DOMAIN domain.local" <- Hier die eigene DNS-Domain eintragen
;push "block-outside-dns" <- ggf. "Einkommentieren", wenn während der VPN-Verbindung auf dem Client keine anderen DNS-Server abgefragt werden sollen

Um ein Plus an Sicherheit zu bekommen, sollte zusätzlich noch eine Anmeldung mittels Benutzername samt Kennwort implementiert werden. Die notwendigen Änderungen sehen wie folgt aus:

auth-user-pass-verify "C:\\Program Files\\OpenVPN\\config-auto\\auth.bat" via-env
script-security 3

Der Inhalt der “auth.bat” ist der folgende:

@echo off

set auth=%username% %password%
find "%auth%" "C:\Program Files\OpenVPN\config-auto\users.txt"
if %errorlevel%==1 exit 1
echo exit 0

Der Inhalt der “users.txt” muss wie folgt aufgebaut sein:

<Benutzername> <Kennwort>

Ein Beispiel:

andy MeinSuperGeheimesKennwort
andreas DasIstMeinPasswort
martin MeineStimmeIstMeinPass

Kurze Erklärung zum “auth”-Skript:

Zuerst werden der Benutzername und das Kennwort in eine Variable geschrieben,
dann wird die Variable in der “users.txt” gesucht,
wird keine Übereinstimmung gefunden, ist der Rückgabewert “1” und damit ist die Anmeldung gescheitert,
andernfalls ist der Rückgabewert “0” und die Anmeldung war erfolgreich.

Persönliche Bemerkung: Dieses Skript sollte gegenüber der Variante aus dem ersten Beitrag einfacher für alle zu verstehen sein.

Hinweis: Immer wenn man Änderungen an der Konfiguration vorgenommen hat, muss der Dienst neu gestartet werden.

Routing

Damit man nicht nur den OpenVPN-Server erreichen kann, muss das Routing in Windows aktiviert werden und entweder im Router oder auf allen zu erreichenden Geräten eine Route bekannt gemacht werden.

In einer Eingabeaufforderung mit erhöhten Rechten auf dem Windows-System, auf dem der OpenVPN-Server installiert ist, Routing für die Schnittstellen aktivieren, die am LAN und VPN beteiligt sind:

netsh interface ipv4 set int "LAN-Verbindung" forwarding=enabled
netsh interface ipv4 set int "OpenVPN TAP-Windows6" forwarding=enabled

Tipp: Die richtigen Schnittstellen-Bezeichnungen können wie folgt ermittelt werden:

netsh interface ipv4 show interfaces

Am Beispiel einer AVM FRITZ!Box 7490 kann eine Route für das VPN wie folgt konfiguriert werden:

  • Im Web-Interface der FRITZ!Box zu “Heimnetzwerk – Netzwerk – Netzwerkeinstellungen” wechseln. Ggf. muss die “Erweiterte Ansicht” aktiviert werden.
  • Bei “LAN-Einstellungen” auf “Erweiterte Einstellungen” klicken.
  • Bei “Statische Routingtabelle” auf “IPv4 Routen” klicken.
  • Auf “Neue IPv4 Route” klicken und wie folgt ausfüllen:
    IPv4-Netzwerk: 10.8.0.0
    Subnetzmaske: 255.255.255.0
    Gateway: 192.168.1.10 <- Hier muss die IP-Adresse des OpenVPN-Servers, also des Computers auf dem OpenVPN installiert ist, eingetragen werden.
  • Den Haken setzen bei “IPv4 Route aktiv”.
  • Auf “OK” und “Übernehmen” klicken.

Alternativ kann bzw. muss man auf jedem zu erreichenden Gerät so eine Route gesetzt werden:

route add <VPN-NETZWERK> mask <SUBNETZMASKE> <OPENVPNSERVER> -p

Ein Beispiel:

route add 10.8.0.0 mask 255.255.255.0 192.168.1.10 -p

Die IP-Adresse 192.168.1.10 muss durch die IP-Adresse des OpenVPN-Servers ersetzt werden.

Firewall

In der Windows-Firewall und sofern ein VPN-Zugriff aus dem Internet erfolgen soll muss jeweils der konfigurierte Port, per Standard ist dies 1194/udp, freigegeben werden.

Kleiner Tipp am Rande: Wer den VPN-Zugriff aus dem Internet einschränken möchte, aber als Router nur eine AVM FRITZ!Box o.ä. einfaches hat, kann in der entsprechenden Regel der Windows-Firewall die Quelle auf bestimmte IP-Adressen begrenzen:

Auf die Frage was mit der Netzwerkkategorie ist, kann dahingehend sozusagen Entwarnung gegeben werden, wenn man DNS in der *.ovpn konfiguriert hat, denn dann erhält die Netzwerkschnittstelle des OpenVPN-Servers ein Präfix. Im Windows-Domänennetzwerk wird so automatisch als Netzwerkkategorie “Domänennetzwerk” für die OpenVPN-Netzwerkkarte festgelegt.

Troubleshooting

Keine Installation ohne Überraschungen möchte man meinen. Während der erste Beitrag zu diesem Thema unter Windows einfach so lief, musste diesmal erst noch eine kleine Änderung vorgenommen werden. Damit der OpenVPN-tun/tap-Netzwerk-Adapter des OpenVPN-Servers vom Dienst eine IP-Adresse erhalten kann, muss ggf. folgender Befehl ausgeführt werden:

netsh interface ipv4 set global dhcpmediasense=enabled

Anschließend den OpenVPN-Server-Dienst neu starten.

Update 07.02.2023: Offenbar wird zumindest unter Windows Server 2022 durch ein Update oder irgendetwas anderes der Wert der “DHCP-Medienerkennung” (DHCP Media Sense) wieder zurückgesetzt (disabled), in Folge erhält der “OpenVPN TAP-Windows6” keine IP-Adresse vom OpenVPN-Server-Dienst (mehr).

Automatisiert prüfen und neu setzen lässt sich das beispielsweise mit einem kleinen Batch-Skript:

@echo off

netsh interface ipv4 show global | find /i "DHCP-Medienerkennung                    : disabled"

if %errorlevel% equ 0 (
 netsh interface ipv4 set global dhcpmediasense=enabled
)

“OpenVPN Wintun” ist davon offenbar nicht betroffen. Entweder man führt den obigen Befehl erneut aus oder man wechselt, wenn möglich, zu Wintun. Für letzteres reicht es aus folgende Zeile in der Server-Konfiguration einzufügen:

windows-driver wintun

Und das Routing für die Schnittstelle zu aktivieren:

netsh interface ipv4 set int "OpenVPN Wintun" forwarding=enabled

OpenVPN-Client

Auf dem Client reicht es aus, OpenVPN mit den Standard-Vorgaben zu installieren und anschließen die Datei

C:\Program Files\OpenVPN\sample-config\client.ovpn

entweder nach

C:\Program Files\OpenVPN\config

oder nach

C:\Users\%username%\OpenVPN\config

zu kopieren. Ans gleiche Ziel müssen zusätzlich noch folgende Dateien kopiert werden:

ca.crt
client.crt
client.key
ta.key

Anschließend editiert man die “client.ovpn” und ändert folgendes ab:

remote <IP oder FQDN des OpenVPN-Servers> 1194
auth-user-pass

Startet man nun aus der OpenVPN-GUI heraus die Verbindung wird nach dem Benutzernamen und Kennwort gefragt und die Verbindung wird aufgebaut.

Persönliche Bemerkung

Es ist schön zu sehen, das man OpenVPN auch unter Windows als Server zum Laufen bekommt und das XCA nach der ersten Erwähnung in diesem Blog im Jahre 2010 (!) immer noch existiert und weiterentwickelt wird. Nichts destotrotz kann der OpenVPN-Server unter Linux oder BSD besser abgesichert werden, siehe

Hardening OpenVPN Security

Wenn man allerdings keine andere Option hat, als einen OpenVPN-Server unter Windows zu betreiben, ist das ein durchaus gangbarer Weg.

Quellen

Andy’s Blog – Application VPN mit Stunnel und XCA

OpenVPN – Support Forum – Server 2012 TAP adapter problem acquiring IP

Microsoft – Docs – So deaktivieren Sie die Funktion “Medienübertragung” für TCP/IP in Windows

OpenVPN- Revoking Certificates

Update 30.01.2022

Diverse Ergänzungen.

Update 24.02.2022

Damit die Prüfung der Zertifikate ob diese evtl. gesperrt sind zuverlässig funktioniert, muss regelmäßig eine neue CRL erzeugt werden. Damit man diesen Vorgang nicht alle 30 Tage manuell vornehmen muss, kann dieser automatisiert werden.

Zuerst muss in XCA bzw. der Datenbank folgende Änderung vorgenommen werden:

Hinweis: Die CLI-Optionen “–no-gui” oder das Äquivalent mittels Variable funktionierten im Test nicht.

Als nächstes benötigt man ein kleines Batch-Skript:

@echo off

rem Konfiguration

 set XCApath=C:\Tools\xca-portable-2.4.0
 set DBpath=C:\Data\XCA
 set DBname=XCA-OpenVPN01.xdb
 set DBpassword=<Das Datenbank-Kennwort>

 cd "C:\Program Files\OpenVPN\config-auto"

rem Neue CRL erzeugen:

 "%XCApath%\xca.exe" --database="%DBpath%\%DBname%" --password="%DBpassword%" --crlgen="OpenVPN-CA" --pem > crl.pem

rem Den OpenVPN-Dienst neu starten

 net stop "OpenVPNService"
 net start "OpenVPNService"

Die “Konfiguration” muss auf die eigene Umgebung angepasst werden!

Dieses Skript lässt man per Aufgabe z.B. monatlich immer am 28. ausführen, denn der Monatserste oder -letzte könnte wegen der vorgegebenen 30 Tagen zu knapp sein.

Wichtig: Hat man Zertifikate gesperrt bzw. zurückgerufen, sollte man gleich um einen etwaigen Missbrauch zu vermeiden eine neue CRL erzeugen!

Zur Info:

Ist eine CRL abgelaufen, wird das im Log des OpenVPN-Servers wie folgt dargestellt:

2022-02-24 10:48:30 <Öffentliche IP-Adresse des Clients>:60821 VERIFY ERROR: depth=0, error=CRL has expired: ...

Also ziemlich eindeutig. Der OpenVPN-Client wiederum kann sich nicht erfolgreich verbinden.

Der Vollständigkeit halber:

In der OpenVPN-Server-Konfiguration kann man

crl-verify OpenVPN-CA-crl.pem

mit einer vorangestellten “#” auskommentieren. Nach einem Dienst-Neustart wird dann überhaupt keine CRL verwendet. Das ist allerdings in Sachen Sicherheit keine all zu gute Idee!

Quellen

xca – Commandline

xca – Certificate Revocation Lists

Ähnliche Artikel:

  1. OpenVPN Site-to-Site mit pfSense als Server und Securepoint UTM als Client
  2. OpenVPN-Server unter Windows einrichten
  3. Windows: VirtualBox & phpVirtualBox – Erste überarbeitete Fassung
  4. Öffentliche IPv4-Adresse an CGN-/DS-Lite-Anschluss mittels vServer und OpenVPN Peer to Peer (SSL/TLS)
  5. Debian, OpenVPN und nftables: Regeln nach Verbindungsaufbau neu laden

Software

42 Kommentare

  1. Florian

    Hallo,

    super Anleitung! Viele Punkte sind schön kleinschrittig erklärt, aber einige andere nicht.
    Z.B. in der Config Datei soll ich die IP 192.168.1.0 eintragen. Ist das fest oder soll ich es abändern, wenn mein normales Netzwerk anders lautet?
    Auch die IP Adresse 192.168.1.10 wird mehrfach verwendet, jedoch kenne ich ihre Aufgabe nicht: Ist das die IP vom OpenVPN Server? Oder vom virtuellen “Ausgang” ins Netzwerk?

    Aktuell bekomme ich beim Versuch einer Verbindung mit dem Android OpenVPN Client einen TLS Timeout und weiß leider nicht, was ich ändern muss.

  2. Andy (Beitragsautor/in)

    > 192.168.1.0

    Das ist nur ein Beispiel, da muss schon das eigene Netz rein.
    Das steht da sogar:

    “push “route 192.168.1.0 255.255.255.0” 192.168.1.10

    Auch das ist nur ein Beispiel, da muss der eigene DNS-Server (wenn es um die Konfig.-Datei geht) bzw. der eigene OpenVPN-Server (wenn es um die Route in der Fritte geht) eingetragen werden.

    > Aktuell bekomme ich beim Versuch einer Verbindung mit dem Android OpenVPN Client einen TLS Timeout und weiß leider nicht, was ich ändern muss.

    Die Timeout-Meldung kommt wo? Auf dem Android oder dem OpenVPN-Server?
    Aufgrund der spärlichen Info muss ich jetzt raten:

    – Port mit richtigem Protokoll freigegeben (sowohl unter Windows als auch im Router)?
    – Läuft der OpenVPN-Dienst?
    – Startet der Dienst Fehlerfrei?
    – Ist das Android-Gerät im gleichen (W)LAN wie der OpenVPN-Server? Falls ja, dann mal aus dem WLAN raus gehen und testen.

    Ansonsten mal anonymisierte Logs und ggf. Konfig.-Dateien posten.

  3. Andy (Beitragsautor/in)

    Der Beitrag wurde etwas ergänzt.

  4. Jürgen

    Hallo Andy,
    super Anleitung! Hab das heute auch nach dieser Anleitung eingerichtet. Trotzdem konnte ich nicht gleich vom Client aus auf das interne Netz zugreifen. Bis ich gemerkt habe, dass das lokale Netz in der Routing Tabelle des Clients fehlt. Aber eigentlich sollte das doch vom Server “gepusht” werden?
    Daraufhin ist im im Logfile des Servers aufgefallen, dass der Paramter “topology subnet” nicht zieht.
    Bei mir musste ich subnet zwingend in Hochkommas setzen, sonst hat ist der Serverdienst nicht gestartet. Und wenn ich die Option ganz weglasse, dann pusht er die Route nicht zum Client.

  5. Andy (Beitragsautor/in)

    Interessant, das hatte ich bislang noch nicht.
    In Hochkomma muss das nur gesetzt werden, wenn vorher ein “push” steht oder das Ganze via ccd gemacht wird.
    Anders hab’ ich das zumindest noch nie gesehen oder erlebt.

  6. Nico

    Kurze Frage: was ist bei “Folgende Änderungen in der Konfigurationsdatei gegenüber dem Original durchführen:

    topology subnet
    push “route 192.168.1.0 255.255.255.0” <- Hier muss das eigene Netz eingetragen werden
    crl-verify crl.pem"
    gemeint? Ich finde unter config nur eine txt datei. wo soll man die Adresse ändern?

  7. Andy (Beitragsautor/in)

    Steht im Beitrag:

    ” Im nächsten Schritt geht es an die Konfiguration, als Basis dient das Beispiel unter

    C:Program FilesOpenVPNsample-configserver.ovpn
    Diese funktioniert nahezu Out-of-the-Box, allein schon mit den Zertifikaten kann man sich bereits anmelden. Es reicht also aus diese Datei in den Ordner

    C:Program FilesOpenVPNconfig-auto
    zu kopieren”

    Diese Datei dann editieren und die Änderungen vornehmen.

  8. Nico

    Aber wenn ich das da rein nehme und speichere kommt folgende Fehlermeldung :Options error: Unrecognized option or missing or extra parameter(s) in server.ovpn:315: explicit-exit-notify (2.5.5)
    Use –help for more information.”

  9. Andy (Beitragsautor/in)

    Nicht einfach rein kopieren, sondern ggf. vorhandene Einträge entsprechend abändern.

  10. Nico

    und wo kommt das crl-verify crl.pem hin? da gibt es in der originalversion doch gar nichts

  11. Andy (Beitragsautor/in)

    Was vorhanden ist, wie beschrieben ändern, was nicht vorhanden ist (neu) hinzufügen.

  12. Nico

    okay, dann gehen wir es nochmal durch:

    topology subnet: steht schon in der datei allerdings mir ; . das semicolon dann einfach entfernen?

    push “route 192.168.1.0 255.255.255.0” <- Hier muss das eigene Netz eingetragen werden
    hier steht das push route schon 2 mal mit einem semicolon. die 2 dann einfach durch push "route 192.168.1.0 255.255.255.0" ohne semicolon ersetzen mit der eigenen ip, auf dem der server laufen soll?

    und crl-verify crl.pem: an welche stelle muss das? einfach ganz ans ende?

    vielen dank schon mal im voraus 🙂

  13. Andy (Beitragsautor/in)

    > topology subnet: steht schon in der datei allerdings mir ; . das semicolon dann einfach entfernen?

    Ja, es steht ja auch ohne Semikolon im Beitrag.
    Vorhandenes gemäß Beitrag und eigene Bedürfnissen (Netz, IP, push…) anpassen.

    > push “route 192.168.1.0 255.255.255.0” hier steht das push route schon 2 mal mit einem semicolon. die 2 dann einfach durch push “route 192.168.1.0 255.255.255.0” ohne semicolon ersetzen mit der eigenen ip, auf dem der server laufen soll?

    Wenn es nur eine Route gibt, dann darf es auch nur ein aktives (ohne Semikolon) “push route…” geben und es wird das Ziel-Netz (z.B. das Firmen-LAN) angegeben, nicht der OpenVPN-Server.

    > und crl-verify crl.pem: an welche stelle muss das? einfach ganz ans ende?

    Völlig egal, Hauptsache ist, das es nur einmal drin steht.
    Generell spielen die Positionen der einzelnen Anweisungen innerhalb der Konfigurationsdatei keine Rolle.

  14. Nico

    Vielen Dank jetzt bin ich ein Schritt weiter.
    Was muss bei “netsh interface ipv4 set int “LAN-Verbindung” forwarding=enabled” für Lan Verbindung und beim folgenden für “OpenVPN TAP-Windows6” eingesetzt werden?

  15. Andy (Beitragsautor/in)

    Die eigenen Netzwerkschnittstellennamen.

  16. Nico

    ich habe leider einen tls error handshake failed. firewall hat die regel mit dem port, auch die route wurde gesetzt. im client.ovpn habe ich bei remote die ip adresse des servers, in der server.ovpn habe ich beim push die netzwerkadresse vom client (endet mit .1) reingeschrieben

  17. Andy (Beitragsautor/in)

    > im client.ovpn habe ich bei remote die ip adresse des servers,

    Die öffentliche IP des Routers oder die LAN-IP des Server?
    Letzteres wäre falsch (außer man arbeitet/testet im LAN versteht sich).

    Die genaue Fehlermeldung wäre hilfreich, denn es kann ein Verschlüsselungsproblem sein, ein Timeout wenn die Client-Verbindung gar nicht bis zum Server durchkommt (Firewall im Weg, Port-Freigabe falsch [z.B. TCP statt UDP]), usw.

    Ist denn sicher, das der Verbindungsversuch vom Client beim Server überhaupt ankommt? Im Zweifelsfall mit SmartSniff, Wireshark o.ä. prüfen!

    Ansonsten die Logs von Client und Server anschauen, i.d.R. steht gut verständlich drin, woran es klemmt.

  18. Nico

    ich hab es jetzt mal auf die des routers geändert.
    Fehlermeldung beim Client:
    Mon Mar 28 12:59:05 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    Mon Mar 28 12:59:05 2022 TLS Error: TLS handshake failed
    Mon Mar 28 12:59:05 2022 SIGUSR1[soft,tls-error] received, process restarting
    Mon Mar 28 12:59:05 2022 Restart pause, 40 second(s)
    Mon Mar 28 12:59:45 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.110.1:1194
    Mon Mar 28 12:59:45 2022 Socket Buffers: R=[180224->180224] S=[180224->180224]
    Mon Mar 28 12:59:45 2022 UDP link local: (not bound)
    Mon Mar 28 12:59:45 2022 UDP link remote: [AF_INET]192.168.110.1:1194
    Mon Mar 28 13:00:45 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    Mon Mar 28 13:00:45 2022 TLS Error: TLS handshake failed
    Mon Mar 28 13:00:45 2022 SIGUSR1[soft,tls-error] received, process restarting
    Mon Mar 28 13:00:45 2022 Restart pause, 80 second(s)

    beim server läuft soweit alles, da steht im log kein fehler.

    laut smartsniff kommt da gar nichts an.

  19. Andy (Beitragsautor/in)

    > Mon Mar 28 12:59:05 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

    Da kommt vmtl. nichts am OpenVPN-Server an.

    > laut smartsniff kommt da gar nichts an.

    Das passt zur obigen Meldung vom Client.

    Ergo muss der Weg zum OpenVPN-Server überprüft werden. Das wäre z.B. die Port-Weiterleitung im Router, wird der Port 1194/udp an den OpenVPN-Server weitergereicht, ist der Port 1194/udp in der Windows-Firewall des OpenVPN-Server freigegeben.

  20. Nico

    ich hab jetzt mal probiert, den server und den client im gleichen netzwerk zu haben. selbst dann scheitert der handshake. die portweiterleitung hab ich gerade nochmal mit route add gemacht und auch der port ist zu 100% freigegeben. langsam ist das ganze zum verzweifeln

  21. Andy (Beitragsautor/in)

    Eine Port-Weiterleitung mit “route add”? Das wäre mir neu.

    Im gleichen Netz benötigt man keine Port-Weiterleitung.

    Die Route wird “nur” für das Transfer-Netz benötigt, sobald der Tunnel steht. Soweit kommt man allerdings offenbar noch gar nicht.

  22. Sylvio

    wo kommt den die “ta.pem” her? das wird in der anleitung nicht beschrieben

  23. Andy (Beitragsautor/in)

    Das war ein Fehler und sollte “ta.key” heißen. Ist behoben. Danke für den Hinweis.

  24. Marcel

    Moin Andy,

    erst einmal vielen Dank für diese Anleitung. Sind meine ersten Versuche mit OpenVPN und ich muss sagen dass Versuch 1 in die Hose ging. Fehlermeldung war das er den Key nicht finden kann. Naja alles runter neuer Versuch. Gut für die Routine. Jetzt bin ich deine Anleitung nochmal gaanz konzentriert durch und habe ein Problem mit dem Export der Zertifikate.

    Du schreibst

    ***”Damit die Zertifikate mit OpenVPN genutzt werden können, müssen diese im richtigen Format exportiert werden. Von der CA an sich wird nur das Zertifikat ohne den privaten Schlüssel benötigt! Vom Server als auch den Clients wird jeweils das Zertifikat mit Schlüssel exportiert.

    Auf der Registerkarte “Zertifikate” das gewünschte Zertifikat auswählen und auf “Export” klicken.
    Das CA-, Server- und die Client-Zertifikate im Format “PEM (*.crt)” als “ca.crt”, “server.crt” und “client.crt” exportieren.
    Auf der Registerkarte “Private Schlüssel” nur die Schlüssel für das Server- und die Client-Zertifikate als “PEM privat (*.pem)” mit dem Dateinamen “server.key” und “client.key” exportieren.”***

    Ich habe bei XCA unter Zertifikate nur das CA, kein Server, kein Client. Wenn ich nach deiner Anleitung “Neues Zertifikat” erstelle und das CA zum unterschreiben benutze dann erhalte ich kein neues Zertifikat sondern nur eine Privaten Schlüssel. Schaue ich mir diesen an sehe ich nirgends dass da das CA benutzt wurde.

    So wie ich die Beschreibung verstehe müsste ich doch insgesamt 3 Zertifikate unter dem Reiter Zertifikate haben oder?

    Ich danke dir für deine Antwort und Hilfe. 🙂

  25. Andy (Beitragsautor/in)

    Hallo Marcel,

    ich hab’ den XCA-Teil gerade nochmal durchgespielt, bei mir funktioniert es wie beschrieben und ja, es sollten am Ende mindestens drei Zertifikate (CA, Server, Client) sein.

    Auf der Registerkarte “Zertifikate” kann man ganz vorne beim CA-Zertifikat die Kette bzw. die Baumstruktur auf- bzw. zuklappen.
    Im zugeklappten Zustand ist da nur ein Pfeil der auf das CA-Zertifikat zeigt, diesen anklicken um alle Zertifikate anzuzeigen.
    Vielleicht ist diese bei dir zugeklappt und daher sieht man die Zertifikate jenseits des CA-Zertifikats nicht.

    Alternativ auf die Schaltfläche “Einfache Ansicht” oder “Baumansicht” klicken.

  26. Benny

    Guten Tag,

    also ich habe soweit alles hinbekommen. Die Verbindung steht.
    Allerdings. Wenn ich im Router den Port 3389 schließe, komme ich nicht meh auf den Server.
    Schließe ich diesen Port nicht, kann ich pe RDP mit oder Ohne OpenVPN auf den Server gelangen.

    Wo kann mein Fehler liegen?
    Beste Grüße

  27. Andy (Beitragsautor/in)

    Vmtl. im RDP-Client die falsche IP-Adresse eingegeben. Da muss nun nicht mehr die öffentliche IP oder FQDN des Routers drin stehen, sondern (bei bestehender VPN-Verbindung) die interne IP des Servers. Wenn DNS auch über VPN genutzt wird kann auch der interne FQDN des Server funktionieren.

  28. Benny Wunsch

    Wenn ich im Client die interne FQDN eintrage, verbindet er sich nicht mehr per OpenVPN. Nur wenn die externe IP hinterlegt es, klappt es mit der Verbindung.
    Wie erwähnt. Ohne das schließen des Ports 3389 kann ich mich auch ohne OpenVPN verbinden.
    Das ist bestimmt wieder nur eine Kleinigkeit. 🙂

  29. Andy (Beitragsautor/in)

    > Wenn ich im Client die interne FQDN eintrage, verbindet er sich nicht

    Was passiert wenn die interne IP eingetragen wird?
    Wird DNS über VPN überhaupt genutzt bzw. ist es konfiguriert?
    Klappt ping, nslookup über VPN?

  30. Benny

    Das ist ein Dedicated Server von Strato. Das dingen hat keine interne IP. zumindest finde ich diese nicht. Mist…
    Sicher das das am Client liegt? Wie gesagt. Die OpenVPN Verbindung steht soweit. Bin leider nicht so stark in der Materie. Wie teste ich das nslookup? Sorry 🙂

  31. Benny

    Ok habe die interne IP wohl gefunden.. ist im 10er Bereich )also 10.0. das was in der Server Datei von OpenVPN eingestellt ist). Aber mit dieser kommt es zu keiner Client Verbindung. irgendwie ausschließlich mit der externen IP des Server klappt das.

  32. Andy (Beitragsautor/in)

    > Das ist ein Dedicated Server von Strato.

    Das ist eine völlig andere Situation wie die, in der im Beitrag ausgegangen wird.

    Ggf. muss man die IP-Bereiche und Windows-Firewall-Einstellungen anpassen.
    Evtl. stimmt auch etwas mit dem Routing nicht.

    Ohne weitere/tiefere Kenntnis von der Umgebung fällt das dann allerdings schwer es so zu klären.

  33. JW

    Wieso gibt es eigentlich keine vernünftige Oberfläche, wo man die erforderlichen Daten eintragen kann? AVM macht es vor, da ist die VPN-Anbindung in wenigen Minuten erledigt, schnell und unkompliziert.

  34. Andy (Beitragsautor/in)

    Es gibt diverse Oberflächen bzw. komplette OpenVPN-Appliances, z.B. in diversen Routern oder als turnkey-Lösung, als Addon für Webmin, usw.
    Für Windows ist mir nichts bekannt, allerdings ist ein OpenVPN-Server unter Windows auch keine wirklich Runde Sache.

    AVM nutzt IPsec und WireGuard, das erste ist je nach Variante ebenso einfach einzurichten wie WireGuard. OpenVPN ist schon alleine wegen der Zertifikate eine ganz andere Hausnummer.

  35. Tom

    Hallo Andy,

    ich habe jetzt 2 Tage verbracht den OpenVPN zu einzurichten auf
    beiden seiten. Ich habe alles im Blog übertragen und angepasst auf mein System mit IP usw..

    Dennoch erhalte ich jetzt diese Fehlermeldung er kann sich einfach nicht anmelden ich weiss nicht warum!

    Kannst Du mir weiterhelfen damit ich diese Verbindung zum laufen bekomme?

    2024-07-27 23:55:05 Note: –cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add ‘–data-ciphers-fallback BF-CBC’ to your configuration and/or add BF-CBC to –data-ciphers.
    2024-07-27 23:55:05 OpenVPN 2.6.12 [git:v2.6.12/038a94bae57a446c] Windows [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Jul 18 2024
    2024-07-27 23:55:05 Windows version 10.0 (Windows 10 or greater), amd64 executable
    2024-07-27 23:55:05 library versions: OpenSSL 3.3.1 4 Jun 2024, LZO 2.10
    2024-07-27 23:55:05 DCO version: 1.2.1
    2024-07-27 23:55:05 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
    2024-07-27 23:55:05 Need hold release from management interface, waiting…
    2024-07-27 23:55:05 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:50466
    2024-07-27 23:55:06 MANAGEMENT: CMD ‘state on’
    2024-07-27 23:55:06 MANAGEMENT: CMD ‘log on all’
    2024-07-27 23:55:06 MANAGEMENT: CMD ‘echo on all’
    2024-07-27 23:55:06 MANAGEMENT: CMD ‘bytecount 5’
    2024-07-27 23:55:06 MANAGEMENT: CMD ‘state’
    2024-07-27 23:55:06 MANAGEMENT: CMD ‘hold off’
    2024-07-27 23:55:06 MANAGEMENT: CMD ‘hold release’
    2024-07-27 23:55:06 MANAGEMENT: >STATE:1722117306,RESOLVE,,,,,,
    2024-07-27 23:55:08 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:55:08 MANAGEMENT: >STATE:1722117308,RESOLVE,,,,,,
    2024-07-27 23:55:10 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:55:10 Could not determine IPv4/IPv6 protocol
    2024-07-27 23:55:10 SIGUSR1[soft,Could not determine IPv4/IPv6 protocol] received, process restarting
    2024-07-27 23:55:10 MANAGEMENT: >STATE:1722117310,RECONNECTING,Could not determine IPv4/IPv6 protocol,,,,,
    2024-07-27 23:55:10 Restart pause, 1 second(s)
    2024-07-27 23:55:11 MANAGEMENT: >STATE:1722117311,RESOLVE,,,,,,
    2024-07-27 23:55:14 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:55:14 MANAGEMENT: >STATE:1722117314,RESOLVE,,,,,,
    2024-07-27 23:55:16 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:55:16 Could not determine IPv4/IPv6 protocol
    2024-07-27 23:55:16 SIGUSR1[soft,Could not determine IPv4/IPv6 protocol] received, process restarting
    2024-07-27 23:55:16 MANAGEMENT: >STATE:1722117316,RECONNECTING,Could not determine IPv4/IPv6 protocol,,,,,
    2024-07-27 23:55:16 Restart pause, 1 second(s)
    2024-07-27 23:55:17 MANAGEMENT: >STATE:1722117317,RESOLVE,,,,,,
    2024-07-27 23:55:19 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:55:19 MANAGEMENT: >STATE:1722117319,RESOLVE,,,,,,
    2024-07-27 23:55:22 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:55:22 Could not determine IPv4/IPv6 protocol
    2024-07-27 23:55:22 SIGUSR1[soft,Could not determine IPv4/IPv6 protocol] received, process restarting
    2024-07-27 23:55:22 MANAGEMENT: >STATE:1722117322,RECONNECTING,Could not determine IPv4/IPv6 protocol,,,,,
    2024-07-27 23:55:22 Restart pause, 1 second(s)
    2024-07-27 23:55:23 MANAGEMENT: >STATE:1722117323,RESOLVE,,,,,,
    2024-07-27 23:55:25 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:55:25 MANAGEMENT: >STATE:1722117325,RESOLVE,,,,,,
    2024-07-27 23:55:27 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:55:27 Could not determine IPv4/IPv6 protocol
    2024-07-27 23:55:27 SIGUSR1[soft,Could not determine IPv4/IPv6 protocol] received, process restarting
    2024-07-27 23:55:27 MANAGEMENT: >STATE:1722117327,RECONNECTING,Could not determine IPv4/IPv6 protocol,,,,,
    2024-07-27 23:55:27 Restart pause, 1 second(s)
    2024-07-27 23:55:28 MANAGEMENT: >STATE:1722117328,RESOLVE,,,,,,
    2024-07-27 23:55:30 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:55:30 MANAGEMENT: >STATE:1722117330,RESOLVE,,,,,,
    2024-07-27 23:55:33 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:55:33 Could not determine IPv4/IPv6 protocol
    2024-07-27 23:55:33 SIGUSR1[soft,Could not determine IPv4/IPv6 protocol] received, process restarting
    2024-07-27 23:55:33 MANAGEMENT: >STATE:1722117333,RECONNECTING,Could not determine IPv4/IPv6 protocol,,,,,
    2024-07-27 23:55:33 Restart pause, 2 second(s)
    2024-07-27 23:55:35 MANAGEMENT: >STATE:1722117335,RESOLVE,,,,,,
    2024-07-27 23:55:37 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:55:37 MANAGEMENT: >STATE:1722117337,RESOLVE,,,,,,
    2024-07-27 23:55:39 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:55:39 Could not determine IPv4/IPv6 protocol
    2024-07-27 23:55:39 SIGUSR1[soft,Could not determine IPv4/IPv6 protocol] received, process restarting
    2024-07-27 23:55:39 MANAGEMENT: >STATE:1722117339,RECONNECTING,Could not determine IPv4/IPv6 protocol,,,,,
    2024-07-27 23:55:39 Restart pause, 4 second(s)
    2024-07-27 23:55:43 MANAGEMENT: >STATE:1722117343,RESOLVE,,,,,,
    2024-07-27 23:55:46 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:55:46 MANAGEMENT: >STATE:1722117346,RESOLVE,,,,,,
    2024-07-27 23:55:48 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:55:48 Could not determine IPv4/IPv6 protocol
    2024-07-27 23:55:48 SIGUSR1[soft,Could not determine IPv4/IPv6 protocol] received, process restarting
    2024-07-27 23:55:48 MANAGEMENT: >STATE:1722117348,RECONNECTING,Could not determine IPv4/IPv6 protocol,,,,,
    2024-07-27 23:55:48 Restart pause, 8 second(s)
    2024-07-27 23:55:56 MANAGEMENT: >STATE:1722117356,RESOLVE,,,,,,
    2024-07-27 23:55:58 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:55:58 MANAGEMENT: >STATE:1722117358,RESOLVE,,,,,,
    2024-07-27 23:56:01 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:56:01 Could not determine IPv4/IPv6 protocol
    2024-07-27 23:56:01 SIGUSR1[soft,Could not determine IPv4/IPv6 protocol] received, process restarting
    2024-07-27 23:56:01 MANAGEMENT: >STATE:1722117361,RECONNECTING,Could not determine IPv4/IPv6 protocol,,,,,
    2024-07-27 23:56:01 Restart pause, 16 second(s)
    2024-07-27 23:56:17 MANAGEMENT: >STATE:1722117377,RESOLVE,,,,,,
    2024-07-27 23:56:19 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:56:19 MANAGEMENT: >STATE:1722117379,RESOLVE,,,,,,
    2024-07-27 23:56:22 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:56:22 Could not determine IPv4/IPv6 protocol
    2024-07-27 23:56:22 SIGUSR1[soft,Could not determine IPv4/IPv6 protocol] received, process restarting
    2024-07-27 23:56:22 MANAGEMENT: >STATE:1722117382,RECONNECTING,Could not determine IPv4/IPv6 protocol,,,,,
    2024-07-27 23:56:22 Restart pause, 32 second(s)
    2024-07-27 23:56:54 MANAGEMENT: >STATE:1722117414,RESOLVE,,,,,,
    2024-07-27 23:56:56 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:56:56 MANAGEMENT: >STATE:1722117416,RESOLVE,,,,,,
    2024-07-27 23:56:58 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:56:58 Could not determine IPv4/IPv6 protocol
    2024-07-27 23:56:58 SIGUSR1[soft,Could not determine IPv4/IPv6 protocol] received, process restarting
    2024-07-27 23:56:58 MANAGEMENT: >STATE:1722117418,RECONNECTING,Could not determine IPv4/IPv6 protocol,,,,,
    2024-07-27 23:56:58 Restart pause, 64 second(s)
    2024-07-27 23:58:02 MANAGEMENT: >STATE:1722117482,RESOLVE,,,,,,
    2024-07-27 23:58:04 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:58:04 MANAGEMENT: >STATE:1722117484,RESOLVE,,,,,,
    2024-07-27 23:58:07 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-27 23:58:07 Could not determine IPv4/IPv6 protocol
    2024-07-27 23:58:07 SIGUSR1[soft,Could not determine IPv4/IPv6 protocol] received, process restarting
    2024-07-27 23:58:07 MANAGEMENT: >STATE:1722117487,RECONNECTING,Could not determine IPv4/IPv6 protocol,,,,,
    2024-07-27 23:58:07 Restart pause, 128 second(s)
    2024-07-28 00:00:15 MANAGEMENT: >STATE:1722117615,RESOLVE,,,,,,
    2024-07-28 00:00:17 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-28 00:00:17 MANAGEMENT: >STATE:1722117617,RESOLVE,,,,,,
    2024-07-28 00:00:19 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-28 00:00:19 Could not determine IPv4/IPv6 protocol
    2024-07-28 00:00:19 SIGUSR1[soft,Could not determine IPv4/IPv6 protocol] received, process restarting
    2024-07-28 00:00:19 MANAGEMENT: >STATE:1722117619,RECONNECTING,Could not determine IPv4/IPv6 protocol,,,,,
    2024-07-28 00:00:19 Restart pause, 256 second(s)
    2024-07-28 00:04:35 MANAGEMENT: >STATE:1722117875,RESOLVE,,,,,,
    2024-07-28 00:04:38 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-28 00:04:38 MANAGEMENT: >STATE:1722117878,RESOLVE,,,,,,
    2024-07-28 00:04:40 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-28 00:04:40 Could not determine IPv4/IPv6 protocol
    2024-07-28 00:04:40 SIGUSR1[soft,Could not determine IPv4/IPv6 protocol] received, process restarting
    2024-07-28 00:04:40 MANAGEMENT: >STATE:1722117880,RECONNECTING,Could not determine IPv4/IPv6 protocol,,,,,
    2024-07-28 00:04:40 Restart pause, 300 second(s)
    2024-07-28 00:09:40 MANAGEMENT: >STATE:1722118180,RESOLVE,,,,,,
    2024-07-28 00:09:42 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-28 00:09:42 MANAGEMENT: >STATE:1722118182,RESOLVE,,,,,,
    2024-07-28 00:09:45 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-28 00:09:45 Could not determine IPv4/IPv6 protocol
    2024-07-28 00:09:45 SIGUSR1[soft,Could not determine IPv4/IPv6 protocol] received, process restarting
    2024-07-28 00:09:45 MANAGEMENT: >STATE:1722118185,RECONNECTING,Could not determine IPv4/IPv6 protocol,,,,,
    2024-07-28 00:09:45 Restart pause, 300 second(s)

  36. Tom

    kurze ergänzung ich habe gesehen das ich diesen eintrag vergessen habe einzutragen in der client.ovp

    remote 1194
    auth-user-pass

    nur erhalte ich jetzt bei verbindungsaufbau folgende meldung in der log datei

    Options error: Unrecognized option or missing or extra parameter(s) in client.ovpn:122: remote (2.6.12)
    Use –help for more information.

    Was hat jetzt für ein Problem?
    Alles sehr mühsam ich würde mich freuen wenn er verbinden würde!

  37. Tom

    Ich erhalte jetzt aktuell nach einer Korrektur der Server ip Adresse
    diese Meldung:

    2024-07-28 01:50:25 Note: –cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add ‘–data-ciphers-fallback BF-CBC’ to your configuration and/or add BF-CBC to –data-ciphers.
    2024-07-28 01:50:25 OpenVPN 2.6.12 [git:v2.6.12/038a94bae57a446c] Windows [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Jul 18 2024
    2024-07-28 01:50:25 Windows version 10.0 (Windows 10 or greater), amd64 executable
    2024-07-28 01:50:25 library versions: OpenSSL 3.3.1 4 Jun 2024, LZO 2.10
    2024-07-28 01:50:25 DCO version: 1.2.1
    2024-07-28 01:50:25 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
    2024-07-28 01:50:25 Need hold release from management interface, waiting…
    2024-07-28 01:50:26 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:57212
    2024-07-28 01:50:26 MANAGEMENT: CMD ‘state on’
    2024-07-28 01:50:26 MANAGEMENT: CMD ‘log on all’
    2024-07-28 01:50:26 MANAGEMENT: CMD ‘echo on all’
    2024-07-28 01:50:26 MANAGEMENT: CMD ‘bytecount 5’
    2024-07-28 01:50:26 MANAGEMENT: CMD ‘state’
    2024-07-28 01:50:26 MANAGEMENT: CMD ‘hold off’
    2024-07-28 01:50:26 MANAGEMENT: CMD ‘hold release’
    2024-07-28 01:50:26 MANAGEMENT: >STATE:1722124226,RESOLVE,,,,,,
    2024-07-28 01:50:28 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-28 01:50:28 MANAGEMENT: >STATE:1722124228,RESOLVE,,,,,,
    2024-07-28 01:50:31 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-28 01:50:31 Could not determine IPv4/IPv6 protocol
    2024-07-28 01:50:31 SIGUSR1[soft,Could not determine IPv4/IPv6 protocol] received, process restarting
    2024-07-28 01:50:31 MANAGEMENT: >STATE:1722124231,RECONNECTING,Could not determine IPv4/IPv6 protocol,,,,,
    2024-07-28 01:50:31 Restart pause, 1 second(s)
    2024-07-28 01:50:32 TCP/UDP: Preserving recently used remote address: [AF_INET]91.1.155.41:1194
    2024-07-28 01:50:32 ovpn-dco device [OpenVPN Data Channel Offload] opened
    2024-07-28 01:50:32 UDP link local: (not bound)
    2024-07-28 01:50:32 UDP link remote: [AF_INET] ********** :1194
    2024-07-28 01:50:32 MANAGEMENT: >STATE:1722124232,WAIT,,,,,,
    2024-07-28 01:50:51 Closing DCO interface
    2024-07-28 01:50:51 SIGTERM[hard,] received, process exiting
    2024-07-28 01:50:51 MANAGEMENT: >STATE:1722124251,EXITING,SIGTERM,,,,,

  38. Tom

    Ich komme nicht weiter ich habe alles nach anleitung im blog gemacht aber ich erhalte ständig diese Fehlermeldung unten!
    Kannst du mir bitte weiterhelfen damit ich eine verbindung aufbauen kann?

    (2024-07-28 02:52:13 MANAGEMENT: >STATE:1722127933,RESOLVE,,,,,,
    2024-07-28 02:52:15 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-28 02:52:15 MANAGEMENT: >STATE:1722127935,RESOLVE,,,,,,
    2024-07-28 02:52:17 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )
    2024-07-28 02:52:17 Could not determine IPv4/IPv6 protocol
    2024-07-28 02:52:17 SIGUSR1[soft,Could not determine IPv4/IPv6 protocol] received, process restarting
    2024-07-28 02:52:17 MANAGEMENT: >STATE:1722127937,RECONNECTING,Could not determine IPv4/IPv6 protocol,,,,,
    2024-07-28 02:52:17 Restart pause, 1 second(s)
    2024-07-28 02:52:18 TCP/UDP: Preserving recently used remote address: [AF_INET]91.1.155.41:1194
    2024-07-28 02:52:18 ovpn-dco device [OpenVPN Data Channel Offload] opened
    2024-07-28 02:52:18 UDP link local: (not bound)
    2024-07-28 02:52:18 UDP link remote: [AF_INET] ******** :1194 (***meine entfernte Server IP)
    2024-07-28 02:52:18 MANAGEMENT: >STATE:1722127938,WAIT,,,,,,
    2024-07-28 02:52:19 Closing DCO interface
    2024-07-28 02:52:19 SIGTERM[hard,] received, process exiting
    2024-07-28 02:52:19 MANAGEMENT: >STATE:1722127939,EXITING,SIGTERM,,,,,

  39. Andy (Beitragsautor/in)

    > 2024-07-28 00:09:45 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )

    Hier kann der Servernamen nicht aufgelöst werden, entweder man nutzt hier eine IP-Adresse oder einen FQDN und nicht nur einen Hostname wie “my-server-1”.

  40. Andy (Beitragsautor/in)

    > remote 1194

    Hier fehlt der FQDN oder die IP des OpenVN-Servers.

    remote

    Port und Protokoll sind optional und nur nötig wenn diese vom Standard (1194/udp) abweichen.

  41. Andy (Beitragsautor/in)

    > 2024-07-28 01:50:28 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )

    Wieder das Thema das der Server nicht aufgelöst werden kann. Also IP oder FQDN verwenden.

  42. Andy (Beitragsautor/in)

    > 2024-07-28 02:52:15 RESOLVE: Cannot resolve host address: my-server-1:1194 (Der angegebene Host ist unbekannt. )

    Und wieder das Gleiche. IP oder FQDN verwenden und, der Vollständigkeit halber, falls noch nicht geschehen, schauen das mit dem DNS alles ok ist.
    Gemeint ist, das der FQDN auch zur IP-Adresse des OpenVPN-Servers aufgelöst werden kann.

2 Pingbacks

  1. OpenVPN-Server unter Windows einrichten – Andy's Blog
  2. WireGuard-Server unter Windows einrichten – Andy's Blog

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

© 2024 Andy's Blog

Theme von Anders Norén — Hoch ↑