OpenVPN - keine Verbindung mit Windows Server 2022

falken214
Goto Top
Hallo liebe Community,
ich arbeite seit etwa 3 Wochen an einem OpenVPN Verbindungsproblem und konnte jetzt hoffentlich eingrenzen worum es geht.
Ich habe auf einem Asus RC86U Router einen OpenVPN Server eingerichtet. Verbindung von MacOS Monterey, Windows 10 Pro, Windows Server 2019 und sogar iOS funktionieren tadellos, Egal welche Clientsoftware (Tunnelblick, OpenVPN Connect V3, OpenVPN GUI).

Ich habe bei Strato einen dedizierten Windows Server gemietet, Firewall seitens Strato ist korrekt konfiguriert, dort werden aber auch nur eingehende Verbindungen gefiltert. Firewall auf dem Server ist aus Testzwecken deaktiviert.
Gestern habe ich testweise bei AWS EC2 einen virtuelle Maschine mit Windows Server 2022 eingerichtet... Auch dort funktioniert die Verbindung nicht. Nun drängt sich der Verdacht auf, dass Windows Server 2022 Standard der Übeltäter ist. Ich habe über VPN Verbindungsfehler gelesen, OpenVPN wurde jedoch dabei nicht erwähnt. Ich habe alle Updates installiert und bin einfach nur noch ratlos.

Vielleicht habt ihr eine Idee?

Ich danke euch im Vorraus

Content-Key: 3099761996

Url: https://administrator.de/contentid/3099761996

Ausgedruckt am: 27.06.2022 um 15:06 Uhr

Mitglied: michi1983
michi1983 17.06.2022 aktualisiert um 11:19:41 Uhr
Goto Top
Hallo,

was sagt denn das Firewall-Log auf den Windows Servern?
Was sagt das OpenVPN Log beim Versuch des Aufbaus der Verbindung?

Gruß
michi
Mitglied: aqui
aqui 17.06.2022 aktualisiert um 11:27:21 Uhr
Goto Top
Wie soll man dir helfen wenn du keinerlei Infos wie OpenVPN Logs, OVPN Konfig Dateien der Windows Server schickst. Du schaffst es ja nicht einmal die "Verbindungsfehler" genauer zu spezifizieren. Was hast du also für eine Erwartung an eine Hilfe die nicht in Kristallkugelei ausarten soll? Kollege @michi1983 hat es oben schon gesagt. Hellsehen kann man auch in einem Admin Forum (noch) nicht. ;-) face-wink
Ein OVPN Log Auszug des OVPN Clients beim Verbindungsaufbau wäre also das Minimum um hier zielführend helfen zu können.
Nur soviel: Bei einem Server musst du beachten das der OVPN Client auch mit entsprechenden Admin Rechten gestartet wird. Die lokale Firewall ist nur die halbe Miete und die auf einem im Internet offenen Windows Server zu deaktivieren ist eh fatal.
Weitere Infos findest du im hiesigen OVPN Tutorial und seinen weiterführenden Links.
Mitglied: falken214
falken214 17.06.2022 um 12:18:10 Uhr
Goto Top
Hallo,
vielen Dank für eure Antwort. Hier erstmal wie der Verbindungsaufbau aussieht:

Fri Jun 17 12:13:57 2022 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
Fri Jun 17 12:13:57 2022 OpenVPN 2.5.7 Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on May 27 2022
Fri Jun 17 12:13:57 2022 Windows version 10.0 (Windows 10 or greater) 64bit
Fri Jun 17 12:13:57 2022 library versions: OpenSSL 1.1.1o 3 May 2022, LZO 2.10
Fri Jun 17 12:13:59 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xxx.xxx.xxx:1194
Fri Jun 17 12:13:59 2022 UDP link local: (not bound)
Fri Jun 17 12:13:59 2022 UDP link remote: [AF_INET]xx.xxx.xxx.xxx:1194

Danach kommt dann dieses:
2022-06-17 12:14:19 SIGTERM[hard,] received, process exiting

Dann geht der ganze bums von vorne los.

Firewall-Log macht ja nur Sinn wenn diese auch aktiviert ist oder?
Mitglied: aqui
aqui 17.06.2022 um 12:33:30 Uhr
Goto Top
Wo ist die OpenVPN Client Konfig? :-( face-sad
Mitglied: falken214
falken214 17.06.2022 um 12:59:48 Uhr
Goto Top
Hier die Client-Config, diese wurde vom OpenVPN Server erstellt, ich habe lediglich die IP geändert.

remote xx.xxx.xxx.xxx 1194
float
nobind
proto udp
dev tun
sndbuf 0
rcvbuf 0
keepalive 10 30
auth-user-pass
client
auth SHA256
cipher AES-256-CBC
remote-cert-tls server
<ca>
</ca>
Mitglied: falken214
falken214 17.06.2022 um 13:01:20 Uhr
Goto Top
Ich habe das Log-level auf Verb 3 gestellt, hat aber keine Änderung gebracht. Wie gesagt, dieses Problem tritt nur bei Windows Server 2022 Standard auf
Mitglied: aqui
aqui 17.06.2022 aktualisiert um 15:40:56 Uhr
Goto Top
Lasse mal alle überflüssigen und kontraproduktiven Parameter wie
  • float
  • nobind
  • sndbuf 0
  • rcvbuf 0
  • client
weg und starte den Client mit Admin Rechten nochmal. Die Client Konfig sollte genau so aussehen:
dev tun
proto udp4
remote xx.xxx.xxx.xxx 1194
ca CA.crt
cert Client1.crt
key Client1.pem
cipher AES-256-CBC
auth SHA256
auth-nocache
tls-client
remote-cert-tls server
persist-tun
persist-key
mute-replay-warnings
pull

Was sagt da das Log?
Die "ca" Tags oben sind vermutlich die Platzhalter der Zertifikate, richtig?
Mitglied: falken214
falken214 20.06.2022 um 08:23:08 Uhr
Goto Top
Guten Morgen,
dank aquis config wurde mir nun folgendes ins Log geschmissen:

2022-06-20 08:10:19 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xxx.xxx.xxx:1194
2022-06-20 08:10:19 UDPv4 link local (bound): [AF_INET][undef]:1194
2022-06-20 08:10:19 UDPv4 link remote: [AF_INET]87.174.194.228:1194
2022-06-20 08:11:19 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2022-06-20 08:11:19 TLS Error: TLS handshake failed
2022-06-20 08:11:19 SIGUSR1[soft,tls-error] received, process restarting
2022-06-20 08:11:36 SIGTERM[hard,init_instance] received, process exiting

Meine Config sieht nun so aus:

dev tun
proto udp4
remote xx.xxx.xxx.xxx 1194
<ca>
-----BEGIN CERTIFICATE
Hier steht dann das Zertifikat
-----END CERTIFICATE

</ca>
cipher AES-256-CBC
auth-user-pass
auth SHA256
auth-nocache
tls-client
remote-cert-tls server
persist-tun
persist-key
mute-replay-warnings
pull

Ich weiß nicht ob es eine richtige Reihenfolge gibt, vielleicht liegt jetzt da der Hund begraben. TLS hab ich via IIS Crypto bereitgestellt:


bildschirmfoto 2022-06-20 um 08.19.39

Ach ja: Verbindung kommt nicht zustande
Mitglied: aqui
aqui 20.06.2022 aktualisiert um 10:10:45 Uhr
Goto Top
Zumindestens gibt es keinen harten Absturz mehr des Clients. ;-) face-wink
Du hast jetzt lediglich noch ein TLS Problem das das Handshaking da nicht klappt.
Das liegt entweder an falschen Keys oder aber der Server ist nicht erreichbar.
Ist der o.a. Log Auszug vom Server oder Client??
Wichtig ist der vom Server! Zeigt das server Log eine eingehende OVPN Verbin dung an kommt der Client zumindestens schonmal durch zum Server und es scheitert dann nur am TLS Handshaking.
Kommt der Client nicht durch liegt das häufig an Firewalls im Pfad. In einer Router Kaskade wird z.B. oft vergessen vorab ein Port Forwarding für UDP 1194 einzurichten usw.
TLS hab ich via IIS Crypto bereitgestellt:
Irgendwie etwas sinnbefreit weil man das bei OpenVPN gar nicht muss und völlig überflüssig ist. Ist ja mit den Easy RSA Tools alles gleich mit an Bord oder man nutzt XCA. Siehe OpenVPN Tutorial.
Eine Reihenfolge gibt es bei der Angabe der Zertifikate nicht, ist also egal.
Mitglied: falken214
falken214 20.06.2022 um 10:51:58 Uhr
Goto Top
Hi,
der Logauszug ist vom Client, der Server gibt mir für diese Verbindung gar nix aus. Vielleicht kommen wir nochmal zur Ausgangslage. Jeder Client, egal welches Betriebssystem( außer Windows Server 2022) kann ohne Probleme eine Verbindung herstellen. Es liegt doch dann nahe das es im OS ein Problem gibt, oder nicht?

Hier auch mal ein Screenshot der Server - config:
bildschirmfoto 2022-06-20 um 10.50.54
bildschirmfoto 2022-06-20 um 10.51.06
Mitglied: aqui
aqui 20.06.2022 um 11:14:57 Uhr
Goto Top
der Server gibt mir für diese Verbindung gar nix aus.
Eigentlich sehr ungewöhnlich. Zumindestens sollte im Setup die Möglichkeit einer Syslog Konfig sein so das man Logging Daten dann auf einem freien Syslog Server schreiben kann wie Kiwi Syslog usw.
Hat der Server einen Shell Zugang über Telnet oder SSH??
Ggf. kann man darüber auch die Log Dateien abfragen.
Die o.a. Konfig ist soweit OK jedenfalls vom GUI aus. Ohne ein Logging oder Debugging und ohne die wirkliche Konfig Datei des Servers zu kennen ist aber einen zielführende Hilfe immer auch Kristallkugelei. :-( face-sad
Die Frage die bleibt ist was diese sinnfreie Nartac Software für einen tieferen Sinn hat?
Wenn man auf einem Router wie deinem einen OpenVPN Server installieren kann MUSS es dort auch immer eine Option geben die dazu passenden Client Zertifikats und Key Dateien zu exportieren.
Mitglied: falken214
falken214 20.06.2022 um 11:52:55 Uhr
Goto Top
passenden Client Zertifikats und Key Dateien zu exportieren.

Ja die Möglichkeit habe ich. Die Software dient nur dazu um in Windows TLS 1.1 und 1.2 zu aktivieren, da diese wohl bei neueren Windows Versionen per default deaktiviert sind, zumindest habe ich so gelesen.

Der Router führt auch ein Systemprotokoll, dort steht aber nix drin über die eine Verbindung. Bei erfolgreicher Verbindung sieht das dann so aus:

Jun 20 11:17:42 vpnserver1[17590]: user/ip peer info: IV_VER=2.5.4
Jun 20 11:17:42 vpnserver1[17590]: user/ip peer info: IV_PLAT=mac
Jun 20 11:17:42 vpnserver1[17590]: user/ip peer info: IV_PROTO=6
Jun 20 11:17:42 vpnserver1[17590]: user/ip peer info: IV_NCP=2
Jun 20 11:17:42 vpnserver1[17590]: user/ip peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:AES-256-CBC
Jun 20 11:17:42 vpnserver1[17590]: user/ip peer info: IV_LZ4=1
Jun 20 11:17:42 vpnserver1[17590]: user/ip peer info: IV_LZ4v2=1
Jun 20 11:17:42 vpnserver1[17590]: user/ip peer info: IV_LZO=1
Jun 20 11:17:42 vpnserver1[17590]: user/ip peer info: IV_COMP_STUB=1
Jun 20 11:17:42 vpnserver1[17590]: user/ip peer info: IV_COMP_STUBv2=1
Jun 20 11:17:42 vpnserver1[17590]: user/ip peer info: IV_TCPNL=1
Jun 20 11:17:42 vpnserver1[17590]: user/ip peer info: IV_GUI_VER="net.tunnelblick.tunnelblick_5770_3.8.7a__build_5770)"
Jun 20 11:17:42 vpnserver1[17590]: user/ip PLUGIN_CALL: POST /usr/lib/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
Jun 20 11:17:42 vpnserver1[17590]: user/ip TLS: Username/Password authentication succeeded for username 'user' [CN SET]
Jun 20 11:17:42 vpnserver1[17590]: user/ip Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jun 20 11:17:42 vpnserver1[17590]: user/ip Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jun 20 11:17:42 vpnserver1[17590]: user/ip Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384

Was mache ich mit dem exportierten Key? In einen Ordner ablegen und darauf in der Client Config verweisen?
Mitglied: falken214
falken214 20.06.2022 um 12:17:43 Uhr
Goto Top
Edit: ich kann eine cert Datei exportieren. Mehr aber auch nicht
bildschirmfoto 2022-06-20 um 12.17.24
Mitglied: aqui
aqui 20.06.2022 aktualisiert um 13:05:28 Uhr
Goto Top
Die Software dient nur dazu um in Windows TLS 1.1 und 1.2 zu aktivieren
Sinnfrei und überflüssig zumindestens für OVPN, denn das TLS kommt vom OVPN selber.
ich kann eine cert Datei exportieren. Mehr aber auch nicht
Nicht nur wie man sieht! Entscheident ist der Export der Konfig Datei. Das wird mit Sicherheit eine .ovn Datei sein oder auch .p12 die alle Zertifikate und die Keys enthält.
Man sieht hier aber den gravierenden Nachteil herstellerproprietärer OVPN Implementationen in Produkte die einem beim VPN Konfigurieren der einfachsten Dinge beraubt zur Konfig und zum Troubleshooting die bei einer klassischen OpenVPN Installation absoluter Standard sind. :-( face-sad
Betreibst du den Asus Router in einer Kaskade oder ist das dein zentraler Internet Router?
Wie sieht es mit dem Syslog Export aus?
Mitglied: falken214
falken214 21.06.2022 um 09:27:19 Uhr
Goto Top
Guten Morgen Aqui,


Sinnfrei und überflüssig zumindestens für OVPN, denn das TLS kommt vom OVPN selber.
Wie auch immer, die Erkenntnis bringt uns leider auch nicht weiter.

Die Configdatei enthält natürlich das Zertifikat.

Der Asus-Router steht hinter einer Fritzbox, dieser hat das port-forwarding auf Port 1194 auf die WAN IP des Asus Routers. Es funktioniert ja, außer in diesem speziellen Fall.

Den Auszug aus dem Syslog hatte ich auch weiter oben, offenbar kommt vom Client nix an.

Kurze allgemeine Frage zum Verständnis:

Wenn ich mit verschiedenen Clients erfolgreich eine Verbindung aufbauen kann, dann sollte doch sowohl die Client als auch die Server Config in Ordnung sein, oder sehe ich das falsch?

Meines Erachtens nach muss irgendwo zwischen Strato Cloud Server mit Win Server 2022 und der Fritzbox, bzw. dem Asus Router die Verbindung via UDP geblockt werden. Ein Ping auf die Ddns funktioniert, ebenso telnet auf geöffnete ports.
Mitglied: aqui
aqui 21.06.2022 aktualisiert um 10:00:33 Uhr
Goto Top
dann sollte doch sowohl die Client als auch die Server Config in Ordnung sein, oder sehe ich das falsch?
Nein, das siehst du richtig. Das liegt dann also ganz speziell nur an diesem einen Client und definitiv nicht an der OpenVPN Konfig.
Strato Cloud Server mit Win Server 2022 und der Fritzbox, bzw. dem Asus Router die Verbindung via UDP geblockt werden.
Dann setze den OpenVPN Tunnel doch testweise mal auf einen der Ephemeral Ports zwischen 49152–65535 die werden in der Regel nie geblockt. Z.B. 51194 oder 61194
Der Asus-Router steht hinter einer Fritzbox
Die Frage die sich da auftut ist dann warum dieses Konstrukt wenn du mit der FB und deren VPN Funktion es auch direkt machen kannst?! Zumal die FB in der aktuellen FW auch Wireguard supportet was allemal besser und performanter ist als das betagte OpenVPN.
Noch viel sinnvoller wäre natürlich ein IKEv2 oder ein L2TP VPN Server was dir dann nicht nur auf dem Windows Server sondern auch bei allen anderen Endgeräten die Frickelei mit dem extra VPN Client ersparen würde
https://administrator.de/content/detail.php?id=562927&token=111#comm ...
https://administrator.de/tutorial/pfsense-vpn-mit-l2tp-ipsec-protokoll-f ...
https://administrator.de/wissen/ipsec-vpn-mobile-benutzer-pfsense-opnsen ...
https://administrator.de/tutorial/ikev2-vpn-server-fuer-windows-und-appl ...
Allemal die deutlich stressfreiere und performantere Lösung als mit der Asus Gurke die immer und immer wieder negativ auffallen:
https://www.heise.de/security/meldung/Asus-Router-koennen-beim-Vorbeisur ...
https://www.heise.de/security/meldung/Asus-Router-schutzlos-bei-Angriffe ...
Vielleich einmal ein Denkanstoß für eine sinnvollere Alternative?!
Mitglied: falken214
falken214 22.06.2022 um 07:57:17 Uhr
Goto Top
Sooo... Also Umstellung auf einen Ephemeral Port, 61194, hat nix gebracht. Warum das ganze?

Der Strato Server hat einen OpenVPN Server vorgeschaltet, so kann ich über das Webinterface von Strato einfach Clients anlegen. Auf dem Server läuft unsere Warenwirtschaft. Da die Fritzbox OpenVPN nicht unterstützt, ist der Asus Router im Prinzip der Client. Alle angeschlossenen Endgeräte haben somit Zugriff auf die Datenbank. Das funktioniert tadellos, Verbesserungsvorschläge sind aber immer willkommen.

Nun braucht der Server eine Verbindung in unser Firmennetz, zum Zeiterfassungsterminal, um die Daten selbstständig zu syncen. Dafür auch diese eine VPN Verbindung. Jetzt mal eine andere Frage:

Könnte das auch über die Fritzbox gehen? Mit einer Portweiterleitung auf das Terminal? Dann würde der Server via Wireguard auf die Fritzbox connecten und von dort weiterleiten an das Terminal?
Mitglied: aqui
aqui 22.06.2022 um 09:21:54 Uhr
Goto Top
Warum das ganze?
DU hast es SELBER vorgeschlagen wegen deines geäußerten Verdachts das der Provider ggf. filtert auf Consumer Anschlüssen und VPN Funktionen so nur teureren Business Anschlüssen vorhält!!
Da die Fritzbox OpenVPN nicht unterstützt, ist der Asus Router im Prinzip der Client.
Warum lässt du denn statt eines vorgeschalteten OpenVPN Servers da nicht eine vorgeschaltete Firewall wie die oben genannten pfSense oder OPNsense laufen?? Damit klappts dann auch mit der FritzBox direkt!
Wäre doch deutlich sinnvoller als deine Frickelei mit dem Asus und einer nicht Standard konformen OpenVPN Implementation dort.
Nun braucht der Server eine Verbindung in unser Firmennetz
Warum ihn dann nicht als VPN Client auf der Firmen FritzBox oder Firmenfirewall einwählen lassen? Wäre auch deutlich einfacher. Zum Thema FritzBoxen im Firmeneinsatz ist hier im Forum ja schon alles gesagt worden. Sowas ist normalerweise ein NoGo und zeigt leider welches Niveau die IT dort hat. Aber anderes Thema...
Jetzt mal eine andere Frage: Könnte das auch über die Fritzbox gehen?
Ja natürlich. Ist ja eben genannt worden. Entweder FB wählt sich per VPN ein oder Server als Client an der FB.
Womit man dann aber wieder beim Thema FBs in Firmen ist was eher dillettantisch und fachfremd ist.
Dann würde der Server via Wireguard auf die Fritzbox connecten
Auch das würde gehen. Idealerweise nimmt man die bordeigenen VPN Clients des Servers mit IKEv2 oder L2TP. Die können das am besten und man muss nicht mit zusätzlicher Software rumfrickeln.
Sieht nicht wirklich so aus das ihr da fachlich fundiert an das Thema rangeht... :-( face-sad
Mitglied: aqui
aqui 27.06.2022 um 14:54:20 Uhr
Goto Top
Wenn es das denn nun war bitte dann auch deinen Thread hier als erledigt schliessen!
Mitglied: falken214
falken214 27.06.2022 um 15:02:22 Uhr
Goto Top
Hallo,
leider war es nix von alledem. Ich hänge noch immer in Windows Server 2022 fest. Dies war und ist ja das ursprüngliche Problem...
Mitglied: aqui
aqui 27.06.2022 aktualisiert um 15:17:10 Uhr
Goto Top
Hast du mit einem Wireshark oder dem MS Paket Sniffer am Server mal gemessen ob der überhaupt OpenVPN Traffic sendet? Das kann ja nur eine Rechte Problematik am Server sein wenn es mit allen anderen OpenVPN Clients fehlerlos klappt.
Ansonsten wechsle das VPN Protokoll.