31
OpenVPN Zertifikat abgelaufen - Verbindung nicht möglich
Hi zusammen,
wie der Titel schon erzählt ist bei unserer Firma das OpenVPN ca.crt zusammen mit den Server Zertifikaten abgelaufen.
Leider ist der Mitarbeiter, der den Dienst vor 10 Jahren aufgebaut hat nicht mehr da und es bereitet mir Schwierigkeiten, den Dienst wieder zum Laufen zu bringen.
Die Frage kursiert ja oft im Netz aber ich hab leider noch nicht die passende Antwort gefunden, weder unter diversen Foren oder unter HOWTO bei der OpenVPN Seite.
Der Dienst ist auf einem WinServer 2008r2 installiert mit Windows 10 Clients.
Nach dem Ablauf des Stammzertifikates ca.crt habe ich mit in der Kommandozeile ein neues erstellt mit dem Befehl build-ca nachdem ich die vars.bat aufgerufen habe, aber nicht den Befehl clean-all benutzt.
Im nächsten Schritt auch neue server.crt zusammen mit server.key und server.csr erstellt mit dem Befehlt build-key-pass.
Die alten Zertifikate verschoben und dafür die neuen auf ihrer Stelle im Ordner platziert so wie die ca.crt auf meinem Client kopiert und dort die alte ca.crt gelöscht.
Auf Server und auf Client die Zertifikate unter vertrauenswürdige Zertifikate installiert.
Leider obwohl die ca.crt ersetzt wurde, versucht der Client bei der Verbindung immer noch das alte Zertifikat abzurufen.
Muss ich die dh2048.pem auch neu erstellen?
Die folgende Fehlermeldung tritt auf:
VERIFY ERROR: depth=0, error=unable to get local issuer certificate: ...
OpenSSL: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed.
zusammen mit den TLS ERROR Reports.
Wie schaffe ich es die neuen Zertifikate zu verifizieren oder signieren damit die Clients das neue Stammzertifikat abrufen?
Gäbe es eine Lösung ohne, dass ich den Dienst komplett vom neuen installiere?
Vielen Dank im Voraus.
Gruß
intane
wie der Titel schon erzählt ist bei unserer Firma das OpenVPN ca.crt zusammen mit den Server Zertifikaten abgelaufen.
Leider ist der Mitarbeiter, der den Dienst vor 10 Jahren aufgebaut hat nicht mehr da und es bereitet mir Schwierigkeiten, den Dienst wieder zum Laufen zu bringen.
Die Frage kursiert ja oft im Netz aber ich hab leider noch nicht die passende Antwort gefunden, weder unter diversen Foren oder unter HOWTO bei der OpenVPN Seite.
Der Dienst ist auf einem WinServer 2008r2 installiert mit Windows 10 Clients.
Nach dem Ablauf des Stammzertifikates ca.crt habe ich mit in der Kommandozeile ein neues erstellt mit dem Befehl build-ca nachdem ich die vars.bat aufgerufen habe, aber nicht den Befehl clean-all benutzt.
Im nächsten Schritt auch neue server.crt zusammen mit server.key und server.csr erstellt mit dem Befehlt build-key-pass.
Die alten Zertifikate verschoben und dafür die neuen auf ihrer Stelle im Ordner platziert so wie die ca.crt auf meinem Client kopiert und dort die alte ca.crt gelöscht.
Auf Server und auf Client die Zertifikate unter vertrauenswürdige Zertifikate installiert.
Leider obwohl die ca.crt ersetzt wurde, versucht der Client bei der Verbindung immer noch das alte Zertifikat abzurufen.
Muss ich die dh2048.pem auch neu erstellen?
Die folgende Fehlermeldung tritt auf:
VERIFY ERROR: depth=0, error=unable to get local issuer certificate: ...
OpenSSL: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed.
zusammen mit den TLS ERROR Reports.
Wie schaffe ich es die neuen Zertifikate zu verifizieren oder signieren damit die Clients das neue Stammzertifikat abrufen?
Gäbe es eine Lösung ohne, dass ich den Dienst komplett vom neuen installiere?
Vielen Dank im Voraus.
Gruß
intane
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 329347
Url: https://administrator.de/contentid/329347
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
31 Kommentare
Neuester Kommentar
Hallo,
die Zertifikate müssen dort hinkopiert werden, wo die OpenVPN config sagt das die Zertifikate (und keys) liegen.
Wenn es pkcs12 sind, dann ist der Key ja schon mit drinnen.
CA Zertifikat vom Server sollte kein Passwort haben.
Normalerweise liegen Config und Zertifikate unter: C:\Program Files\OpenVPN\config
Also wenn auf dem Client das CA Zertifikat und die Clientzertifikate an der richtigen Stelle sind sollte es gehen.
Gruß
Chonta
die Zertifikate müssen dort hinkopiert werden, wo die OpenVPN config sagt das die Zertifikate (und keys) liegen.
Wenn es pkcs12 sind, dann ist der Key ja schon mit drinnen.
CA Zertifikat vom Server sollte kein Passwort haben.
Normalerweise liegen Config und Zertifikate unter: C:\Program Files\OpenVPN\config
Also wenn auf dem Client das CA Zertifikat und die Clientzertifikate an der richtigen Stelle sind sollte es gehen.
Gruß
Chonta
Die Version ist bisschen älter (2.3.4) deswegen sind die keys separat.
Das ist eigentlich kein Problem, da ich die drei Dateien (.key .csr .crt) mitkopiere.
In der Server.ovpn config ist der Speicherort der Zertifikate unter:
ca c:programmeopenvpnkeysca.crt
cert c:programmeopenvpnkeysserver.crt
key c:programmeopenvpn keysserver.key
(edit Forum kürzt Doppelslash weg)
angegeben und nicht der config Ordner, aber das hat mit der alten CA funktioniert.
Die neue CA wurde auch dorthin kopiert aber leider ohne Erfolg.
Auch der Versuch die CA in den config Ordner zu packen wirkte nicht.
Auf dem Client sind die Zertifikate korrekterweise in dem config Ordner.
Bei der Erstellung der ca.crt kommt keine Frage um ein Passwort zu setzen, ist von daher ohne.
Passwort geschützt ist aber die server.crt, muss die vielleicht ohne sein?
Leider kommt immer noch die Meldung:
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
Gruß
intane
Das ist eigentlich kein Problem, da ich die drei Dateien (.key .csr .crt) mitkopiere.
In der Server.ovpn config ist der Speicherort der Zertifikate unter:
ca c:programmeopenvpnkeysca.crt
cert c:programmeopenvpnkeysserver.crt
key c:programmeopenvpn keysserver.key
(edit Forum kürzt Doppelslash weg)
angegeben und nicht der config Ordner, aber das hat mit der alten CA funktioniert.
Die neue CA wurde auch dorthin kopiert aber leider ohne Erfolg.
Auch der Versuch die CA in den config Ordner zu packen wirkte nicht.
Auf dem Client sind die Zertifikate korrekterweise in dem config Ordner.
Bei der Erstellung der ca.crt kommt keine Frage um ein Passwort zu setzen, ist von daher ohne.
Passwort geschützt ist aber die server.crt, muss die vielleicht ohne sein?
Leider kommt immer noch die Meldung:
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
Gruß
intane
Das Serverzertifikat muss auch ohne Paswort sien, ja, sonst kann der OpenVPN Dienst das nicht verwenden.
Gruß
Chonta
Gruß
Chonta
Ok Serverzertifikat aktualisiert und bei der Passwort abfrage die Felder leer gelassen, funktioniert leider auch nicht.
Die Frage ist, mob der befehl build-key-pass falsch ist, da die ein leeres Passwortfeld auch als Passwort vielleicht angenommen wird.
Der Befehl um ein Zertifikat ohne Passwort zu erstellen ist build-key?
Weil der funktioniert nicht.
Gruß
intane
Die Frage ist, mob der befehl build-key-pass falsch ist, da die ein leeres Passwortfeld auch als Passwort vielleicht angenommen wird.
Der Befehl um ein Zertifikat ohne Passwort zu erstellen ist build-key?
Weil der funktioniert nicht.
Gruß
intane
Wenn OpenVPN das Zertifikat nicht nuten kann würde der Dienst nicht starten.
Kopiere die Zertifikate dorthin wo die Config ist die vom Binary genutzt wird.
Oder
Mit richtigen Pfardangaben und mit " " wenn der Pfad Leerzeichen hat.
Du kannst die Zertifikate auch auf einem anderem system erstellen, wichtig ist nur Server und Clients brauchen alle Zertifikate von der selben CA und dann passt das.
Der DH muss nicht neu gemacht werden.
Ggf. mal das Log posten. (einen Auszug)
Gruß
Chonta
Kopiere die Zertifikate dorthin wo die Config ist die vom Binary genutzt wird.
ca ca.crt
cert server.crt
key server.keyOder
Mit richtigen Pfardangaben und mit " " wenn der Pfad Leerzeichen hat.
Du kannst die Zertifikate auch auf einem anderem system erstellen, wichtig ist nur Server und Clients brauchen alle Zertifikate von der selben CA und dann passt das.
Der DH muss nicht neu gemacht werden.
Ggf. mal das Log posten. (einen Auszug)
Gruß
Chonta
Die Zertifikate sind am Speicherort der von Server.ovpn genutzt werden.
Der Fehler liegt womöglich am server.crt das beim Erstellen eine Fehlermeldung erzeugt, bzw. TXT_DB error, wahrscheinlich weil die Zertifikate gerade benutzt werden.
Außerdem meckert beim erzeugen des neuen server.crt, dass nach dem Befehl: build-key-pass server kein Passwort kommt.
Gibt es eventuell einen anderen Befehl ohne Passwortabfrage?
Welche wäre also der korrekte cmd Befehl zum erzeugen des Serverzertifikates.
Per cmd meckert ovpn öfter wenn man ein Zertifikat aktualisieren möchte..
Die CA wurde aktualisiert, sodass sie bei CLient und und Server die selbe ist.
Der Fehler liegt womöglich am server.crt das beim Erstellen eine Fehlermeldung erzeugt, bzw. TXT_DB error, wahrscheinlich weil die Zertifikate gerade benutzt werden.
Außerdem meckert beim erzeugen des neuen server.crt, dass nach dem Befehl: build-key-pass server kein Passwort kommt.
Gibt es eventuell einen anderen Befehl ohne Passwortabfrage?
Welche wäre also der korrekte cmd Befehl zum erzeugen des Serverzertifikates.
Per cmd meckert ovpn öfter wenn man ein Zertifikat aktualisieren möchte..
Die CA wurde aktualisiert, sodass sie bei CLient und und Server die selbe ist.
VERIFY ERROR: depth=0, error=unable to get local issuer certificate: C=DE, ST=B, O=server, CN=server, emailAddress=---
Tue Feb 14 14:55:13 2017 OpenSSL: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Tue Feb 14 14:55:13 2017 TLS_ERROR: BIO read tls_read_plaintext error
Tue Feb 14 14:55:13 2017 TLS Error: TLS object -> incoming plaintext read error
Tue Feb 14 14:55:13 2017 TLS Error: TLS handshake failed
Leg die Zertifikate mal von Hand über Powershell oder auf Linux mit openssl an.
Und versuche es dann nochmal.
Die Aktuelle Version von OpenVPN am besten auch verwenden, wenn nicht installiert.
Oder auch auf Windows mit openssl , wenn openssl installiert wurde.
Gruß
Chonta
Und versuche es dann nochmal.
Die Aktuelle Version von OpenVPN am besten auch verwenden, wenn nicht installiert.
Oder auch auf Windows mit openssl , wenn openssl installiert wurde.
Gruß
Chonta
Habe eben nachgeschaut im easy-rsa Ordner existiert nur die build-key-pass.bat aus dem Grund konnte ich nicht einfach nur build-key ausführen.
Welche wären die richtigen Befehle um eine neue server.crt zu erzeugen, die ich über die Powershell benutzen kann, bzw. gibt es eine Liste davon?
Könnte der Fehler darin liegen, dass die Software Version veraltet ist?
Gruß
intane
Welche wären die richtigen Befehle um eine neue server.crt zu erzeugen, die ich über die Powershell benutzen kann, bzw. gibt es eine Liste davon?
Könnte der Fehler darin liegen, dass die Software Version veraltet ist?
Gruß
intane
nd es bereitet mir Schwierigkeiten, den Dienst wieder zum Laufen zu bringen.
Warum ? Ein neues Zertifikat ist in 10 Minuten erstellt:OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Was soll daran schwer sein ?
ein neues erstellt mit dem Befehl build-ca
Richtig gemacht !aber nicht den Befehl clean-all benutzt.
Schlecht 
Im nächsten Schritt auch neue server.crt zusammen mit server.key und server.csr erstellt mit dem Befehlt build-key-pass.
Wieder richtig !Die alten Zertifikate verschoben
Besser komplett löschen um Probleme sicher zu vermeiden, sind ja eh nutzlos geworden !Auf Server und auf Client die Zertifikate unter vertrauenswürdige Zertifikate installiert.
Nee, falsch. Diese zeritfikate haben mit den Winblows Systemzertifikaten nix zu tun und sind separat !Deshalb ist das auch gleich prompt schief gegangen.
Sie dir die server.conf Datei auf dem OVPN Server an, die sagt dir in welchem Verzeichnis die Zertifikate stehen.
In der Regel ist das immer das easy-rsa Verzeichnis.
versucht der Client bei der Verbindung immer noch das alte Zertifikat abzurufen.
Das kommt weil du sie im Verzeichnis nicht gleich komplett gelöscht hast. Du solltest nur noch mit den Neuen arbeiten.Und dran denken das Zertifikatsverzeichnis von OVPN hat nichts mit dem Winblows Zerts zu tun !!
Gäbe es eine Lösung ohne, dass ich den Dienst komplett vom neuen installiere?
Ja natürlich. Du musst nix neu machen. Nur allte Zertifikatsdateien komplett löschen, neue generieren und in das entsprechende Zert Verzeichnis kopieren wenn sie nicht schon per default drin sind.Client Zertifikate genereien und auf die Clients in deren zert Verzeichnis kopieren.
Das wars.
Halte dich an das o.a. Tutorial. Die Zert Generierung auf OVPN ist für alle Plattformen immer gleich !
In den letzten Stunden es geschafft die richtige ca.crt zu erstellen aber leider nicht die richtigen Server.crt.
Bei dem Versuch mit den Befehlen build-key-pass die Zertifikate ohne pw zu erstellen kommt der Fehler TXT_DB error number 2..
Ich könnte eventuell ein neues Server Zertifikat mit einem neuen Namen erstellen ist wohl die Frage ob das möglich wäre ohne, dass die Fehlermeldung: *.old Not found aufkommt.
Bei dem Versuch mit den Befehlen build-key-pass die Zertifikate ohne pw zu erstellen kommt der Fehler TXT_DB error number 2..
Ich könnte eventuell ein neues Server Zertifikat mit einem neuen Namen erstellen ist wohl die Frage ob das möglich wäre ohne, dass die Fehlermeldung: *.old Not found aufkommt.
Wie die Zertifikate heißen ist vollkommen unwichtig, Du musst die nur in der Konfig für den richtigen Zweck eintragen und gut ist.
Gruß
Chonta
Gruß
Chonta
Alles klar, Zertifikate (CA, server.crt, neue Client Zertifikate).
Verbindung konnte erfolgreich aufgebaut werden, leider ist der Netzwerk Zugriff noch nicht da, sprich die DFS Verzeichnisse sind nicht erreichbar.
Gibt es noch eine Verknüpfung die konfiguriert werden müsste?
Gruß
intane
Verbindung konnte erfolgreich aufgebaut werden, leider ist der Netzwerk Zugriff noch nicht da, sprich die DFS Verzeichnisse sind nicht erreichbar.
Gibt es noch eine Verknüpfung die konfiguriert werden müsste?
Gruß
intane
OpenVPN auf dem Client als Administrator (mit Adminrechten) gestartet?
Ohne können die Routen nicht gesetzt werden und dann geht nur die Verbindung zum VPN Server aber nicht weiter.
Wenn an den Konfigs nix außer den Zertifikaten geändert wurde, kann es nur daran liegen, außer es hat vorher schon nicht funktioniert.
Gruß
Chonta
Ohne können die Routen nicht gesetzt werden und dann geht nur die Verbindung zum VPN Server aber nicht weiter.
Wenn an den Konfigs nix außer den Zertifikaten geändert wurde, kann es nur daran liegen, außer es hat vorher schon nicht funktioniert.
Gruß
Chonta
Ja als Administrator ausgeführt, das war auch davor klar, der Dienst lief ja bis zum Zertifikatablauf.
In der Anleitung steht, dass die dh erstellt werden muss aber du meintest die muss man ja nicht nochmal erstellen ne.
In der server.ovpn wurden nur die neuen server.crt umbenannt sonnst blieben die Pfade gleich.
Was spielt die Datei serial für eine Rolle und die ca.key sollte nur auf Serverseite bleiben richtig?
Gruß
intane
In der Anleitung steht, dass die dh erstellt werden muss aber du meintest die muss man ja nicht nochmal erstellen ne.
In der server.ovpn wurden nur die neuen server.crt umbenannt sonnst blieben die Pfade gleich.
Was spielt die Datei serial für eine Rolle und die ca.key sollte nur auf Serverseite bleiben richtig?
Gruß
intane
ca.key sollte nur auf Serverseite
Der CA key sollte nur bei der CA sein und den braucht auch der Server nicht der Server braucht das CA Zertifikt, sein Zertifikat und seinen Key.Wenn das Symbol grün wird, dann besteht ja die Verbindung, wenn dann was nicht klappt, liegt es nicht an den Zertifikaten.
Es kann vorkommen das OpenVPN den Arp nicht löschen kann und dann wird die VErbindung zwar grün, aber man erreicht keinen.
Gruß
Chonta
Ja die Verbindung zeigt grün.
Müsste dann wahrscheinlich woanders hapern..
Wie überprüfe ich ob die Arp richtig gelöscht wird, bzw. wie konfiguriere ich den Löschvorgang richtig?
Gruß
intane
Müsste dann wahrscheinlich woanders hapern..
Wie überprüfe ich ob die Arp richtig gelöscht wird, bzw. wie konfiguriere ich den Löschvorgang richtig?
Gruß
intane
Wie überprüfe ich ob die Arp richtig gelöscht wird,
Das siehst Du im Log wenn sich der Client verbindet, wenn nicht ist das Loglevel nicht brauchbar.Dan steht dann sher offt. das versucht wird den ARP zu löschen, und irgendwann ist die Verbindung grün, aber man erreicht niemanden.
Client neustaren und dann gleich kann helfen und oder Open-VPN in der aktuellen Version rüberbügeln.
Gruß
Chonta
Wed Feb 15 12:24:32 2017 OPTIONS IMPORT: timers and/or timeouts modified
Wed Feb 15 12:24:32 2017 OPTIONS IMPORT: --ifconfig/up options modified
Wed Feb 15 12:24:32 2017 OPTIONS IMPORT: route options modified
Wed Feb 15 12:24:32 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed Feb 15 12:24:32 2017 ROUTE_GATEWAY (192.168.44.254)/255.255.255.0 I=11 HWADDR=(mac address)
Wed Feb 15 12:24:32 2017 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Feb 15 12:24:32 2017 MANAGEMENT: >STATE:1487157872,ASSIGN_IP,,10.8.8.14,
Wed Feb 15 12:24:32 2017 open_tun, tt->ipv6=0
Wed Feb 15 12:24:32 2017 TAP-WIN32 device [TAP] opened: \\.\Global\{673390B4-698D-495E-904A-39C551C616CC}.tap
Wed Feb 15 12:24:32 2017 TAP-Windows Driver Version 9.21
Wed Feb 15 12:24:32 2017 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.8.14/255.255.255.0 on interface {673390B4-698D-495E-904A-39C551C616CC} [DHCP-serv: 10.8.8.0, lease-time: 31536000]
Wed Feb 15 12:24:32 2017 Successful ARP Flush on interface [9] {673390B4-698D-495E-904A-39C551C616CC}
Wed Feb 15 12:24:37 2017 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
Wed Feb 15 12:24:37 2017 MANAGEMENT: >STATE:1487157877,ADD_ROUTES,,,
Wed Feb 15 12:24:37 2017 C:\Windows\system32\route.exe ADD 192.168.44.0 MASK 255.255.255.0 10.8.8.1 METRIC 1
Wed Feb 15 12:24:37 2017 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4
Wed Feb 15 12:24:37 2017 Route addition via IPAPI succeeded [adaptive]
Wed Feb 15 12:24:37 2017 Initialization Sequence Completed
Wed Feb 15 12:24:37 2017 MANAGEMENT: >STATE:1487157877,CONNECTED,SUCCESS,10.8.8.14Im Auzug aus dem Client Log steht der Satz: Successful ARP Flush on interface, bedeutet mit der ARP alles richtig?
Client öfter neugestartet, die Version ist relativ neu des Clients, ich könnte versuchen noch ne neuere drauf zu machen.
Jap ARP ist ok.
Kommst Du auf den Server über VPN per RDP oder so rauf?
Das Clientnetz hat aber nicht den selben IP-Bereich wie das Zielnetz?
Was sagen die Routingtabellen von Server und Client?
Versuchst Du einen anderen Server als den VPN-Server zu erreichen? Wenn ja kennen die Clients/das Gateway die Route ins VPN Netz?
Gruß
Chonta
Kommst Du auf den Server über VPN per RDP oder so rauf?
Das Clientnetz hat aber nicht den selben IP-Bereich wie das Zielnetz?
Was sagen die Routingtabellen von Server und Client?
Versuchst Du einen anderen Server als den VPN-Server zu erreichen? Wenn ja kennen die Clients/das Gateway die Route ins VPN Netz?
Gruß
Chonta
Normalerweise per DFS Verzeichnisse aber RDP klappt auch.
Nein ich versuche es von einer externen IP.
Die Routing Tabellen haben sich nicht geändert, da wie erwähnt alles noch lief letzte Woche.
Ich versuche direkt den VPN-Server zu erreichen, die Clients sollten die Route kennen, die hat sich ja nicht geändert, es wurden nur neue Zertifikate erstellt.
Das neue server.crt Zertifikat hat einen anderen Namen als das alte, aber in der config wurde es umbenannt, ist momentan nur die Frage ob man den neuen Namen auch woanders eintragen muss.
Serverdienst wurde auch schon neugestartet.
Gruß
intane
Nein ich versuche es von einer externen IP.
Die Routing Tabellen haben sich nicht geändert, da wie erwähnt alles noch lief letzte Woche.
Ich versuche direkt den VPN-Server zu erreichen, die Clients sollten die Route kennen, die hat sich ja nicht geändert, es wurden nur neue Zertifikate erstellt.
Das neue server.crt Zertifikat hat einen anderen Namen als das alte, aber in der config wurde es umbenannt, ist momentan nur die Frage ob man den neuen Namen auch woanders eintragen muss.
Serverdienst wurde auch schon neugestartet.
Gruß
intane
RDP klappt auch.
Klappt oder klappt nicht?Normalerweise
Was Du normalerweise versucht zu erreichen ist zum Testen doch egal.Nein ich versuche es von einer externen IP.
?? Vpn steht also RDP Verbindung zum Server über die VPN IP und auch ein Versuch \\openvpn-ip-vom-server\Und danach mit der IP des OpenVPN-Servers aus dem Firmennetzwerk.
momentan nur die Frage ob man den neuen Namen auch woanders eintragen muss.
Also der Dateiname des Zertifikates ist egal, ausgestellt sollte es schon auf den fqdn und die IP vom Server sein, aber selbst wenn nicht wäre das egal.Die einzige Frage derzeit ist, wie weit und wohin kommst Du über den VPN Tunnel und wenn das geklärt ist kann man weiter machen.
Wenn alles noch so wäre wie vorher, müsste jetzt auch alles funktionieren.
Gruß
Chonta
Tut mir leid meinte, es klappte davor momentan nicht.
Ich komme weder per RDP oder per DFS auf das Firmenntzwerk.
Mittlerweile auf der 2.4 Client Version upgedated.
Eine IP habe ich ja schon bekommen und der Tunnel Adapter ist verbunden.
Es ist momentan komisch, dass die Verbindung aufgebaut ist aber kein Zugriff auf das Netzwerk da ist.
Gruß
intane
Ich komme weder per RDP oder per DFS auf das Firmenntzwerk.
Mittlerweile auf der 2.4 Client Version upgedated.
Eine IP habe ich ja schon bekommen und der Tunnel Adapter ist verbunden.
Es ist momentan komisch, dass die Verbindung aufgebaut ist aber kein Zugriff auf das Netzwerk da ist.
Gruß
intane
Geht ein Ping auf die OpenVPN IP des Servers?
Wie hast Du versucht Dich zu verbeinden?
Lass dir bitte nicht alles aus der Nase ziehen.
Wenns vorher ging und jetzt nicht, dann muss sich ja irgendwas geändert haben.
Gruß
Chonta
Wie hast Du versucht Dich zu verbeinden?
Lass dir bitte nicht alles aus der Nase ziehen.
Wenns vorher ging und jetzt nicht, dann muss sich ja irgendwas geändert haben.
Gruß
Chonta
Ne der Ping findet leider keine der IP Adressen.
Verbunden habe ich mich durch die Ordnerstruktur (Ordnerpfad) bzw. durch RDP.
Joa eigentlich sind die einzigen Änderungen die Server Zertifikate, neue Client Zertifikate, da die alten nicht mehr gingen und die CA..
Bin auch noch am Suchen an welchem Punkt die Verbindung nicht aufgebaut können kann, ob die neue Zertifikate eventuell nicht durch die Firewall kommen.
Gruß
intane
Verbunden habe ich mich durch die Ordnerstruktur (Ordnerpfad) bzw. durch RDP.
Joa eigentlich sind die einzigen Änderungen die Server Zertifikate, neue Client Zertifikate, da die alten nicht mehr gingen und die CA..
Bin auch noch am Suchen an welchem Punkt die Verbindung nicht aufgebaut können kann, ob die neue Zertifikate eventuell nicht durch die Firewall kommen.
Gruß
intane
Immer in das OpenVPN Log sehen. Dort sollte alles drinstehen. Zur Not den verbose Level erhöhen !
Ja das Log bin ich die letzte Zeit am Vergleichen zwischen dem "jetzt" und dem "davor" wo es funktioniert hat.
Wie erhöhe ich den verbose Level?
Habe mich bis jetzt noch nicht damit beschäftigt.
Wie erhöhe ich den verbose Level?
Habe mich bis jetzt noch nicht damit beschäftigt.
"c:programmeopenvpnconfigcrl.pem is from a different issuer than the issuer of certificate"
Eventuell ist dieser Satz bzw. ausschlaggebend.
Wobei ist ja egal wann die erstellt wurde..
Eventuell ist dieser Satz bzw. ausschlaggebend.
Wobei ist ja egal wann die erstellt wurde..
Nein das ist auch wichtig.
Wenn eine CRL eingesetzt wird muss die auch stimmen und von der jetzigen CA kommen.
Oder man verwendet keine CRL
Das kommt davon wenn man keine Kompletten Konfigs postet
Ich weiß nicht wie sich OpenVPN verhält wenn die CRL (Liste mit abgelehnten Zertifikaten) nicht zur verwendeten CA passt, gut möglich das dann alles geblockt wird.
Gruß
Chonta
Wenn eine CRL eingesetzt wird muss die auch stimmen und von der jetzigen CA kommen.
Oder man verwendet keine CRL
Das kommt davon wenn man keine Kompletten Konfigs postet
Ich weiß nicht wie sich OpenVPN verhält wenn die CRL (Liste mit abgelehnten Zertifikaten) nicht zur verwendeten CA passt, gut möglich das dann alles geblockt wird.
Gruß
Chonta
Beide Server Logs verglichen (alte funktionierende und neues mit den neuen Zertifikaten) und keien Verfehlungen gefunden..
hmm eventuell komplett einmal den VPN Server neustarten und nicht nur den Dienst.
Gruß
intane
hmm eventuell komplett einmal den VPN Server neustarten und nicht nur den Dienst.
Gruß
intane
Verbindung erfolgreich nach Neustart des OVPN Servers hergestellt.
Da am Ende alles richtig eingestellt war, war es komisch da es nicht direkt ging.
Danke für die Hilfe!
Gruß
intane
Da am Ende alles richtig eingestellt war, war es komisch da es nicht direkt ging.
Danke für die Hilfe!
Gruß
intane
Glückwunsch ! Gut wenn nun alles rennt wie es soll.
