OpenVPN keine Verbindung vom Client
Hallo,
ich habe OpnVPN eingerichtet für einen Server und einen Client.
Das OS ist bei beiden Windows 8.1. Auf dem Server habe ich erfolgreich eine Verbindung aufgebaut und es erscheint verbunden mit Server IP10.0.0.1
Die Windows Firewall ist bei beiden Rechnern ausgeschaltet. Die Portweiterleitung ist auf einer Fritz!Box 7390 eingerichtet auf den Port Udp 1194.
Die sebguhl.ddns.net lässt sich anpingen. Der Verbindungsversuch erfolgt vom Client nicht über das lokale Netzwerk.
Die OpenVPN-gui.exe wird mit Administratorrechten gestartet. Die Fehlermeldung die dann ausgegeben wird ist:
Verbindung zu Client ist fehlgeschlagen!
Eine Log Datein wird erst gar nicht erzeugt. Folgender Test funktioniert nicht:
C:\Programme\OpenVPN\config>..\bin\openvpn.exe --config server.ovpn
Die config - Datei vom Client sieht so aus:
Bitte um Hilfe!
VG Mike
ich habe OpnVPN eingerichtet für einen Server und einen Client.
Das OS ist bei beiden Windows 8.1. Auf dem Server habe ich erfolgreich eine Verbindung aufgebaut und es erscheint verbunden mit Server IP10.0.0.1
Die Windows Firewall ist bei beiden Rechnern ausgeschaltet. Die Portweiterleitung ist auf einer Fritz!Box 7390 eingerichtet auf den Port Udp 1194.
Die sebguhl.ddns.net lässt sich anpingen. Der Verbindungsversuch erfolgt vom Client nicht über das lokale Netzwerk.
Die OpenVPN-gui.exe wird mit Administratorrechten gestartet. Die Fehlermeldung die dann ausgegeben wird ist:
Verbindung zu Client ist fehlgeschlagen!
Eine Log Datein wird erst gar nicht erzeugt. Folgender Test funktioniert nicht:
C:\Programme\OpenVPN\config>..\bin\openvpn.exe --config server.ovpn
Die config - Datei vom Client sieht so aus:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
remote sebguhl.ddns.net
# die öffentliche IP (oder dyndns-Name) des Routers auf der Server-Seite
port 1194
# legt den zu verwendenen Port fest (muß gleich dem Port beim Server sein)
proto udp
dev tap
dev-node openvpn
# Achtung: Groß-/Kleinschreibung beachten
tls-client
# "ich bin der Client"
ca "C:\\Programme\\OpenVPN\\easy-rsa\\keys\\ca.crt"
# vollständige Pfadangabe ergänzen, doppelte "\\" beachten
key "C:\\Programme\\OpenVPN\\easy-rsa\\keys\\vpnclient01.key"
cert "C:\\Programme\\OpenVPN\\easy-rsa\\keys\\vpnclient01.crt"
ns-cert-type server
# der Server überprüft die Zertifikate auf Gültigkeit
comp-lzo
pull
# "pull" muß in der Client-config stehen, damit die push-Anweisungen
# vom Server geholt werden
Die folgenden Einstellungen dienen dazu, die Verbindung stabiler gegen Verbindungsabbrüche zu machen und legt die Protokollierstufe fest. Die client.ovpn kann optional mit diesen ergänzt werden.
Code:
tun-mtu 1500
tun-mtu-extra 32
# siehe Hinweis oben: wenn "tun-mtu" und "tun-mtu-extra",
# dann in beiden configs (Server + Client)
verb 3
mute 50
persist-key
persist-tun
log-append openvpn.log
Bitte um Hilfe!
VG Mike
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 254857
Url: https://administrator.de/forum/openvpn-keine-verbindung-vom-client-254857.html
Ausgedruckt am: 11.04.2025 um 03:04 Uhr
14 Kommentare
Neuester Kommentar
der Client geht über eine Tethering Verbindung über mein Smartphone ins Internet.
..das könnte so schon zum Problem werden.Die UMTS-Provider machen in der Regel NAPT (Network Address Port Translation).
Es läuft, wenn Du Glück hast ein OpenVPN-Client, den Server brauchst Du gar nicht erst versuchen, da kein DynDNS funktioniert.
Du solltest die Konfiguration erst mal an einem normalen DSL, bzw. mit 2 verbundenen Rechnern im LAN testen (conf. entsprechend anpassen), bevor Du mit einem Smartphone a´ la Windows loslegst.
Gruß orcape
Grundlegende Hilfe dazu auch hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Die config - Datei vom Client sieht so aus:
remote 192.168.178.21 1194
das ist die private IP Deiner Fritzbox, wie soll da der Client eine Verbindung initiieren.remote 192.168.178.21 1194
Du brauchst da schon Deinen DynDNS-Eintrag oder eine Feste-IP auf dem WAN-Interface Deiner Fritte.
Auch wenn Du da ein Portforwarding gemacht hast.
Gruß orcape
Kollege Orcape hat Recht. Beim Server sieht soweit alles gut aus...
Unter remote a.b.c.d wir die Ziel IP Adresse des Servers definiert. Das ist per se erstmal richtig !
Da du ja schreibst du hast das in einem Testaufbau auf gesetzt wäre wichtig zu erfahren WO denn jetzt der Client angeschlossen ist bzw. WIE der im Testaufbau mit deinem Server direkt kommuniziert ??
Bedenke das beide Geräte (Server und Cient) nicht im selben IP Segment liegen dürfen.
Du hast zudem noch einen Kardinalsfehler in deiner Server Konfig, denn dort fehlt das Push Route Kommando das das lokale LAN des Servers an den Client in die Route Table sendet.
Deine Server Konfig oben bewirkt das ein VPN Client einzig nur den Server per VPN erreichen kann und sonst nix. Wenn dir das reicht ist das OK und kein Fehler.
Die Pool Kommandos in interne IP Zuweisung (Zeile 17 und 20) ist übrigens vollkommen überflüssig. Das kann man mit einer einzigen simplen Zeile server 10.0.0.0 255.255.255.0 erledigen. Den Rest erledigt dann OVPN automatisch so das auch Zeile 45 damit obsolet ist !
Dein Grundproblem ist aber das der Client hier scheinbar NICHT den Server IP seitig erreichen kann. Das siehst du an den vollkommen fehlenden Log Einträgen bei einem Verbindungsversuch !!
Ein fast sicheres Indiz das die UDP 1194er VPN Pakete entweder in der lokalen Client Firewall oder in der lokalen Server Firewall hängenbleiben !!
Ein typischer Winblows Fehler, denn denn die Winblows typische Netzwerk Detection kann das IP netzwerk des virtuellen Tunnel Adapters nicht zuordnen und nimmt dann ein öffentliches netzwerk an mit dem entsprechenden Profil. Das blockt aber gnadenlos jeden Traffic der eingehend ist.
Mit dem Ergebnis das du siehst !!
Konzentrier dich also auf den Bereich oder deaktiviere komplett das Firewalling bei beiden !
Unter remote a.b.c.d wir die Ziel IP Adresse des Servers definiert. Das ist per se erstmal richtig !
Da du ja schreibst du hast das in einem Testaufbau auf gesetzt wäre wichtig zu erfahren WO denn jetzt der Client angeschlossen ist bzw. WIE der im Testaufbau mit deinem Server direkt kommuniziert ??
Bedenke das beide Geräte (Server und Cient) nicht im selben IP Segment liegen dürfen.
Du hast zudem noch einen Kardinalsfehler in deiner Server Konfig, denn dort fehlt das Push Route Kommando das das lokale LAN des Servers an den Client in die Route Table sendet.
Deine Server Konfig oben bewirkt das ein VPN Client einzig nur den Server per VPN erreichen kann und sonst nix. Wenn dir das reicht ist das OK und kein Fehler.
Die Pool Kommandos in interne IP Zuweisung (Zeile 17 und 20) ist übrigens vollkommen überflüssig. Das kann man mit einer einzigen simplen Zeile server 10.0.0.0 255.255.255.0 erledigen. Den Rest erledigt dann OVPN automatisch so das auch Zeile 45 damit obsolet ist !
Dein Grundproblem ist aber das der Client hier scheinbar NICHT den Server IP seitig erreichen kann. Das siehst du an den vollkommen fehlenden Log Einträgen bei einem Verbindungsversuch !!
Ein fast sicheres Indiz das die UDP 1194er VPN Pakete entweder in der lokalen Client Firewall oder in der lokalen Server Firewall hängenbleiben !!
Ein typischer Winblows Fehler, denn denn die Winblows typische Netzwerk Detection kann das IP netzwerk des virtuellen Tunnel Adapters nicht zuordnen und nimmt dann ein öffentliches netzwerk an mit dem entsprechenden Profil. Das blockt aber gnadenlos jeden Traffic der eingehend ist.
Mit dem Ergebnis das du siehst !!
Konzentrier dich also auf den Bereich oder deaktiviere komplett das Firewalling bei beiden !
@aqui
..auch unterschiedliche IP-Netze ?
Mit der Winblows-Firewall wirst Du wohl nicht ganz falsch liegen.

Gruß orcape
Bedenke das beide Geräte (Server und Cient) nicht im selben IP Segment liegen dürfen.
TAP-Device..auch unterschiedliche IP-Netze ?
Mit der Winblows-Firewall wirst Du wohl nicht ganz falsch liegen.
Der Test erfolgt nun nur lokal im eigenen Netz.
...das hatte ich überlesen.Gruß orcape
Das Kommando push "route-gateway 10.0.0.1" ist definitiv falsch auf dem Server ! Dort sollte:
push "route 192.168.1.0 255.255.255.0" stehen !
Wobei die 192.168.1.0 hier das lokale LAN Netzwerk des Servers ist ! Das solltest du korrigieren.
Hilfreich wäre dann einmal das Server Log hier zu posten wenn du einen Verbindungsaufbau startest um zu sehen das eingehende OVPN Pakete (UDP 1194) dort überhaupt ankommen. Alternativ auch hier einen Sniffer wie Wireshark oder Windows NetMonitor laufen lassen.
Starte parallel auch mal einen Wireshark Sniffer auf dem Client und sieh mal nach ob überhaupt Antwortpakete vom OVPN Server kommen.
Grob sieht es so aus also ob zwischen Client und Server irgendwo ne Firewall oder NAT existiert die den Zugriff blockt !
Wie sieht den Testszenario aus ?
Wo ist der Client und wo ist der Server ? Sind da NAT Router / Firewalls dazwischen ? Ist das eine Real Life Umgebung ?
push "route 192.168.1.0 255.255.255.0" stehen !
Wobei die 192.168.1.0 hier das lokale LAN Netzwerk des Servers ist ! Das solltest du korrigieren.
Hilfreich wäre dann einmal das Server Log hier zu posten wenn du einen Verbindungsaufbau startest um zu sehen das eingehende OVPN Pakete (UDP 1194) dort überhaupt ankommen. Alternativ auch hier einen Sniffer wie Wireshark oder Windows NetMonitor laufen lassen.
Starte parallel auch mal einen Wireshark Sniffer auf dem Client und sieh mal nach ob überhaupt Antwortpakete vom OVPN Server kommen.
Grob sieht es so aus also ob zwischen Client und Server irgendwo ne Firewall oder NAT existiert die den Zugriff blockt !
Wie sieht den Testszenario aus ?
Wo ist der Client und wo ist der Server ? Sind da NAT Router / Firewalls dazwischen ? Ist das eine Real Life Umgebung ?
die Server log funktioniert leider nicht:
Warum nicht ?? Im Default ist das immer aktiv und du kannst den gesamten Login Prozess mitlesen ?Hast du das deaktiviert ?
Wireshark zeigt keinen positiven echo request beim Verbindungsaufbau an
Wiese "beim Verbindungsaufbau" ?? Da gibts ja gar keinen Ping. Pingen kannst du erst wenn die VPN Verbindung steht !Den echo request solltest du aber immer sehen können ! Wenn nicht dann werkelt irgendwo noch eine Firewall die ICMP blockt bei dir !
der Server ist über seine IP 192.168.178.21 erreichbar
Lokal im LAN oder wie ?? Das ist klar das das geht. Wichtig ist aber einzig der Ping übers VPN !Das Tablet (Client) zum Test ist einfach im lokalen WLAN Netz und der PC (Server) ist per LAN Kabel im lokalen Netzwerk.
Das kann so nicht gehen ! Der Client muss in einem separatem Netz sein wie es auch in Wirklichkeit der Fall ist. Ansonsten will der Server per "push route" die lokale Route an den Client schicken der im gleichen netz ist und das gibt dann ein Routing Problem da der Client das gleiche Netz dann einmal lokal und einmal remote sieht und die Verbindung abbricht.Die Logdatei funktionier bei beiden Rechnern nicht!?
Wie gesagt: WARUM nicht ?? Auch das ist schonmal nicht normal bei dir ! Irgendwas ist da ziemlich faul mit deiner Installation !