OpenVPN "kaputt"

TuberPlays · 29. Oktober 2018

Hallo,

ich benutze eine Sophos Firewall mit der Open-VPN Funktion um bei uns ins Firmennetz zu kommen.

Seit 2 Tagen habe ich allerdings das Problem, dass ich mit meinem Windows 10 Rechner (OpenVPN Client) nach dem Verbinden keine IP-Adresse bekomme. Open-VPN zeigt zwar an, dass die Verbindung "verbunden" ist, aber der TAP-Adapter bekommt keine IP-Adresse zugewiesen.

Wenn ich das gleiche Profil (das bisher ja auch funktioniert hat) auf meinem Smartphone importiere funktioniert alles wunderbar.

Jemand ne Idee? Alles vom Smartphone aus zu machen wird ab 3 RDP Sitzungen lästig

Markchen · 29. Oktober 2018

Sophos-VPN beenden. Als Administrator ausführen. Testen. Das Problem besteht sporadisch, dass er für das Routing nicht genug Rechte hat. Manchmal hat er auch Probleme, wenn das Passwort mit einer Zahl endet, diese nicht vom der des Token (falls ihr sowas einsetzt) unterscheiden kann. Evtl. auch mal den Client neu installieren. Vorher unter Programme\sophos den Inhalt vom Verzeichnis Config löschen.

C:\Program Files (x86)\Sophos\Sophos SSL VPN Client\config

rocketworm · 29. Oktober 2018

Ggf. mal den Client in der aktuelln Version von der UTM runterziehen und installieren. Ich habe das schon ein paar mal gehabt, dass nach einem Update auf der UTM der alte Client nicht mehr mit der FW funktionierte.

TuberPlays · 29. Oktober 2018

Markchen schrieb:
Sophos-VPN beenden

Ich glaube, wir reden da aneinander vorbei. Ich importiere die .ovpn Datei in den offiziellen Open-VPN client. Nichts Sophos-Spezifisches. Weder am Rechner, noch am Smartphone

rocketworm schrieb:
Ggf. mal den Client in der aktuelln Version von der UTM runterziehen

siehe oben

Markchen · 29. Oktober 2018

Eigentlich nur, wenn sich die Zertifikate ändern. Aber einen Versuch ist das auch Wert!

@TE kommst Du auf das Benutzerportal?

TuberPlays · 29. Oktober 2018

Markchen schrieb:
kommst Du auf das Benutzerportal?

Ja. Darauf komme ich von außen drauf. Allerdings auch ohne VPN.

Markchen · 29. Oktober 2018

Wie alt ist die .ovpn-Datei? Wie gesagt, evtl. hat sich was an der Config geändert. Und starte den Open-VPN mal als Admin.

Ergänzung (29. Oktober 2018)

TuberPlays schrieb:
Ja. Darauf komme ich von außen drauf. Allerdings auch ohne VPN.

So solls auch sein. Ist ja die externe Adresse der Sophos.

TuberPlays · 29. Oktober 2018

Markchen schrieb:
Wie alt ist die .ovpn-Datei?

Mit der, die ich gerade getestet habe, 10 Minuten.

Markchen schrieb:
Wie gesagt, evtl. hat sich was an der Config geändert

Da die Firewall unter meiner Fuchtel steht, kann ich dir verbindlich sagen nein

Update wurde vor ca. 2 Monaten eins gemacht.

Markchen schrieb:
starte den Open-VPN mal als Admin

Bringt leider auch nichts.

Habe im Log weiterhin im Sekundentakt
Mon Oct 29 19:09:40 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Mon Oct 29 19:09:40 2018 Route: Waiting for TUN/TAP interface to come up...

Raijin · 29. Oktober 2018

Grundsätzlich empfiehlt es sich, bei Konfigurationsproblemen auch die Konfigurqtion zur Begutachtung zu posten. Das Problem kann nämlich nicht zuletzt auch aus einer fehlerhaften oder zumindest unüblichen Konfiguration resultieren.

Wie dem auch sei, man kann dem Client auch in seiner eigenen Config eine IP verpassen. Analog zu "ifconfig-push", welches einem Client vom Server aus gezielt eine IP aufs Auge drücken kann (in einer ccd-Datei) kann man auch in der Client-Konfiguration direkt "ifconfig" verwenden. Das ist naturgemäß fehleranfällig, wenn damit quasi eine statische IP im DHCP-Bereich des VPNs liegt.

TuberPlays · 29. Oktober 2018

Raijin schrieb:
Grundsätzlich empfiehlt es sich, bei Konfigurationsproblemen auch die Konfigurqtion zur Begutachtung zu posten

Ein bisschen zensiert, biddeschön

# OVPN_ACCESS_SERVER_USERNAME=#MY USERNAME#

client
dev tun
proto tcp
remote #REMOTE IP#
;verify-x509-name "C=de, L=#STADT#, O=#FIRMENNAME#, CN=fw01, emailAddress=#MAIL-ADRESSE#"
;route remote_host 255.255.255.255 net_gateway
resolv-retry infinite
nobind
persist-key
persist-tun
auth-user-pass
cipher AES-128-CBC
auth SHA1
comp-lzo
route-delay 4
verb 3
reneg-sec 86400
<ca>
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
#ENTFERNT#
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=de, L=#STADT#, O=#FIRMENNAME#, CN=#FIRMENNAME# VPN CA/emailAddress=#MAIL-ADRESSE#
Validity
Not Before: Jul 9 12:30:15 2018 GMT
Not After : Jan 1 00:00:00 2038 GMT
Subject: C=de, L=#STADT#, O=#FIRMENNAME#, CN=#FIRMENNAME# VPN CA/emailAddress=#MAIL-ADRESSE#
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
#ENTFERNT#
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
#ENTFERNT#
X509v3 Basic Constraints:
CA:TRUE
X509v3 Subject Alternative Name:
IP Address:127.0.0.1
Signature Algorithm: sha256WithRSAEncryption
#ENTFERNT#
-----BEGIN CERTIFICATE-----
#ENTFERNT#
-----END CERTIFICATE-----
</ca>
<cert>
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
#ENTFERNT#
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=de, L=#STADT#, O=#FIRMENNAME#, CN=#FIRMENNAME# VPN CA/emailAddress=#MAIL-ADRESSE#
Validity
Not Before: Aug 29 10:26:37 2018 GMT
Not After : Jan 1 00:00:01 2038 GMT
Subject: C=de, L=#STADT#, O=#FIRMENNAME#, CN=#PERSONALNAME#
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
#ENTFERNT#
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
#ENTFERNT#
X509v3 Authority Key Identifier:
keyid:32:#ENTFERNT#
DirName:/C=de/L=#STADT#/O=#FIRMENNAME#/CN=#FIRMENNAME# VPN CA/emailAddress=#MAIL-ADRESSE#
serial:#ENTFERNT#

X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
Signature Algorithm: sha256WithRSAEncryption
#ENTFERNT#
-----BEGIN CERTIFICATE-----
#ENTFERNT#
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
#ENTFERNT#
-----END PRIVATE KEY-----
</key>

Raijin · 29. Oktober 2018

Zu jeder client.conf bzw. .ovpn gibt's auch ne server.conf bzw. .ovpn. Die finale Konfiguration des Clients ergibt sich immer erst zur Laufzeit, weil der Server unter Umständen Kommandos pusht. Den cert- bzw ca-Block brauchst du nicht zu zensieren, sondern lässt ihn am besten ganz weg, weil 80% der geposteten Konfiguration nun aus irrelevanten, zensierten Zertifikaten besteht (= extrem unübersichtlich).

Neben der Konfiguration sind auch die Logos interessant. Der Auszug, den du gepostet hast bzw. die zwei Zeilen sind nur die Folgefehler des ursprünglichen Fehlers, der fehlenden IP. Nix IP -> nix Route. Du zeigst hier nur den Teil mit nix Route, aber der Teil mit nix IP ist deutlich interessanter. Aber bitte nicht nur 2 Zeilen mit nix IP aus dem Log rauskopieren, sondern das vollständige Log posten.

TuberPlays · 30. Oktober 2018

Moin,

Raijin schrieb:
Zu jeder client.conf bzw. .ovpn gibt's auch ne server.conf bzw. .ovpn. Die finale Konfiguration des Clients ergibt sich immer erst zur Laufzeit, weil der Server unter Umständen Kommandos pusht.

ich glaube, wir reden da ein bisschen aneinander vorbei. An der Config/ am Server "kann" es eigendlich nicht liegen. An meinem Smartphone funktioniert die Config wunderbar, genau so wie auf meinem zweiten "Testnotebook". Ergo such ich eher die Lösung dafür, wie ich OpenVPN auf meinem Rechner wieder zum laufen bekommen.

BTW:
Ich hab auch mal eine Kundenconfig probiert, die überall anderst auch wunderbar funktioniert. Bekommt mit meinem Rechner auch keine IP.

Grüße

Raijin · 30. Oktober 2018

Dann kann ich dir nicht helfen. Wenn du meinst, dass du weißt wo der Fehler liegt und wo er nicht liegt, dann bist du scheinbar schon gut bedient.

Nur mal so: Ein OpenVPN-Server kann client-spezifische Kommandos pushen, die zB an Client A gepusht werden, aber nicht an Client B. Ich sage ja nicht, dass der Fehler tatsächlich in der server.conf liegt - evtl nutzt du ccd ja gar nicht, ABER ich kann es auch nicht ausschließen, weil ich nun mal die server.conf nicht kenne.

Bedenke, dass die Helfer im Forum nicht neben dir stehen, wenn das Problem auftritt. Das heißt, dass wir ausschließlich auf Basis der Informationen, die du uns gibst, urteilen können. So ist wie schon erwähnt das vollständige Log interessant und nicht nur die zwei Zeilen, von denen du meinst, dass sie die einzig relevanten Zeilen sind. Das heißt nicht, dass andere im übrigen Log sofort das Problem identifizieren können, aber eine KFZ-Werkstatt liest auch den kompletten Fehlerspeicher aus und verlässt sich nicht nur auf die Aussagen des Kunden.

Es gibt nun mal nicht "die" Ursache für Problem XY, sondern der Fehler kann aus verschiedenen Gründen auftreten. Um das zu beurteilen, benötigt man zwangsläufig umfassende Informationen.

TuberPlays · 1. November 2018

Raijin schrieb:
Wenn du meinst, dass du weißt wo der Fehler liegt und wo er nicht liegt, dann bist du scheinbar schon gut bedient.

Ich sage ja nicht, dass hier eh alle doof sind und nur ich den heiligen Graal gefunden habe.

Nur habe ich ja schon mehrfach geschreieben, dass die Config (auch schon auf diesem Rechner) funktioniert hatte. Ich hab gestern mal was ausprobiert: Ich hab vor ca. 2 Wochen die Netzwerkkarte (PCIe Einsteckkarte) getauscht. Seither haut die Verbindung nicht mehr hin. Testweise mal die alte Karte wieder rein und zack, Verbindung da. Daher meine Vermutung (Windows zählt die Adapter ja durch, drum hei´t das jetzt nicht mehr "Netzwerk 5", sondern "Netzwerk 6") dass Open-VPN nicht mehr "weiß", dass es die Pakete auf die neue Physikalische Schnittstelle legen muss um raus zu kommen.

Raijin schrieb:
Um das zu beurteilen, benötigt man zwangsläufig umfassende Informationen.

Thu Nov 01 12:58:47 2018 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Thu Nov 01 12:58:47 2018 Windows version 6.2 (Windows 8 or greater) 64bit
Thu Nov 01 12:58:47 2018 library versions: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10
Enter Management Password:
Thu Nov 01 12:58:47 2018 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Thu Nov 01 12:58:47 2018 Need hold release from management interface, waiting...
Thu Nov 01 12:58:47 2018 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Thu Nov 01 12:58:47 2018 MANAGEMENT: CMD 'state on'
Thu Nov 01 12:58:47 2018 MANAGEMENT: CMD 'log all on'
Thu Nov 01 12:58:47 2018 MANAGEMENT: CMD 'echo all on'
Thu Nov 01 12:58:47 2018 MANAGEMENT: CMD 'bytecount 5'
Thu Nov 01 12:58:47 2018 MANAGEMENT: CMD 'hold off'
Thu Nov 01 12:58:47 2018 MANAGEMENT: CMD 'hold release'
Thu Nov 01 12:58:50 2018 MANAGEMENT: CMD 'username "Auth" "#USERNAME#"'
Thu Nov 01 12:58:50 2018 MANAGEMENT: CMD 'password [...]'
Thu Nov 01 12:58:50 2018 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Thu Nov 01 12:58:50 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]#OUR_IP#:1194
Thu Nov 01 12:58:50 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Thu Nov 01 12:58:50 2018 Attempting to establish TCP connection with [AF_INET]#OUR_IP#:1194 [nonblock]
Thu Nov 01 12:58:50 2018 MANAGEMENT: >STATE:1541073530,TCP_CONNECT,,,,,,
Thu Nov 01 12:58:51 2018 TCP connection established with [AF_INET]#OUR_IP#:1194
Thu Nov 01 12:58:51 2018 TCP_CLIENT link local: (not bound)
Thu Nov 01 12:58:51 2018 TCP_CLIENT link remote: [AF_INET]#OUR_IP#:1194
Thu Nov 01 12:58:51 2018 MANAGEMENT: >STATE:1541073531,WAIT,,,,,,
Thu Nov 01 12:58:51 2018 MANAGEMENT: >STATE:1541073531,AUTH,,,,,,
Thu Nov 01 12:58:51 2018 TLS: Initial packet from [AF_INET]#OUR_IP#:1194, sid=9471f714 17d23d2f
Thu Nov 01 12:58:51 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Nov 01 12:58:52 2018 VERIFY OK: depth=1, C=de, L=#STADT#, O=#FIRMENNAME#, CN=#FIRMENNAME# VPN CA, emailAddress=info@#FIRMENNAME#.de
Thu Nov 01 12:58:52 2018 VERIFY OK: depth=0, C=de, L=#STADT#, O=#FIRMENNAME#, CN=fw01, emailAddress=info@#FIRMENNAME#.de
Thu Nov 01 12:58:52 2018 Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Thu Nov 01 12:58:52 2018 [fw01] Peer Connection Initiated with [AF_INET]#OUR_IP#:1194
Thu Nov 01 12:58:53 2018 MANAGEMENT: >STATE:1541073533,GET_CONFIG,,,,,,
Thu Nov 01 12:58:53 2018 SENT CONTROL [fw01]: 'PUSH_REQUEST' (status=1)
Thu Nov 01 12:58:54 2018 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.242.2.1,route-gateway 10.242.2.1,topology subnet,ping 10,ping-restart 120,route 192.168.1.0 255.255.255.0,dhcp-option DNS 192.168.1.20,dhcp-option DNS 192.168.1.11,ifconfig 10.242.2.2 255.255.255.0'
Thu Nov 01 12:58:54 2018 OPTIONS IMPORT: timers and/or timeouts modified
Thu Nov 01 12:58:54 2018 OPTIONS IMPORT: --ifconfig/up options modified
Thu Nov 01 12:58:54 2018 OPTIONS IMPORT: route options modified
Thu Nov 01 12:58:54 2018 OPTIONS IMPORT: route-related options modified
Thu Nov 01 12:58:54 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Nov 01 12:58:54 2018 Outgoing Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
Thu Nov 01 12:58:54 2018 Outgoing Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 01 12:58:54 2018 Incoming Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
Thu Nov 01 12:58:54 2018 Incoming Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 01 12:58:54 2018 interactive service msg_channel=608
Thu Nov 01 12:58:54 2018 ROUTE_GATEWAY 192.168.2.1/255.255.255.0 I=9 HWADDR=80:c1:6e:64:db:bd
Thu Nov 01 12:58:54 2018 open_tun
Thu Nov 01 12:58:54 2018 TAP-WIN32 device [Ethernet] opened: \\.\Global\{38E77824-FB8F-478C-82DE-EBBBB4F5EA79}.tap
Thu Nov 01 12:58:54 2018 TAP-Windows Driver Version 9.21
Thu Nov 01 12:58:54 2018 Set TAP-Windows TUN subnet mode network/local/netmask = 10.242.2.0/10.242.2.2/255.255.255.0 [SUCCEEDED]
Thu Nov 01 12:58:54 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.242.2.2/255.255.255.0 on interface {38E77824-FB8F-478C-82DE-EBBBB4F5EA79} [DHCP-serv: 10.242.2.254, lease-time: 31536000]
Thu Nov 01 12:58:54 2018 Successful ARP Flush on interface [3] {38E77824-FB8F-478C-82DE-EBBBB4F5EA79}
Thu Nov 01 12:58:54 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Nov 01 12:58:54 2018 MANAGEMENT: >STATE:1541073534,ASSIGN_IP,,10.242.2.2,,,,
Thu Nov 01 12:58:58 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:58:58 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:02 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:02 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:03 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:03 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:04 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:04 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:05 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:05 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:07 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:07 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:08 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:08 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:09 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:09 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:10 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:10 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:11 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:11 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:12 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:12 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:13 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:13 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:14 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:14 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:15 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:15 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:16 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:16 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:17 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:17 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:19 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:19 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:20 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:20 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:21 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:21 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:22 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:22 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:23 2018 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Nov 01 12:59:23 2018 Route: Waiting for TUN/TAP interface to come up...
Thu Nov 01 12:59:23 2018 Closing TUN/TAP interface
Thu Nov 01 12:59:23 2018 NOTE: Release of DHCP-assigned IP address lease on TAP-Windows adapter failed: Dem Endpunkt der Netzwerkverbindung ist noch keine Adresse zugeordnet. (code=1228)
Thu Nov 01 12:59:23 2018 SIGTERM[hard,] received, process exiting
Thu Nov 01 12:59:23 2018 MANAGEMENT: >STATE:1541073563,EXITING,SIGTERM,,,,,

Raijin · 1. November 2018

Hm.. Also laut Log hat der Server dem VPN-Client angeblich erfolgreich eine IP-Adresse verpasst.

Thu Nov 01 12:58:54 2018 Set TAP-Windows TUN subnet mode network/local/netmask = 10.242.2.0/10.242.2.2/255.255.255.0 [SUCCEEDED]

Prüfe zunächst ob der TAP-Adapter im Netzwerkcenter evtl. bereits mit einer falschen IP konfiguriert wurde und somit vielleicht gar nicht auf eine Zuweisung vom DHCP reagiert bzw. diese gar nicht erst anfragt.

Ansonsten könntest du nun mal zwei Dinge ausprobieren:

1) Zuweisungs-Modus ändern
--> client.ovpn --> ip-win32 netsh

Damit wird die IP nun explizit mit dem Tool "netsh" zugewiesen. Im Log sieht das dann so aus:

Thu Nov 01 14:17:18 2018 NETSH: C:\Windows\system32\netsh.exe interface ip set address myVPN static 10.8.0.2 255.255.255.0
Thu Nov 01 14:17:19 2018 NETSH: C:\Windows\system32\netsh.exe interface ip delete dns myVPN all
Thu Nov 01 14:17:20 2018 NETSH: C:\Windows\system32\netsh.exe interface ip set dns myVPN static 10.8.0.1
Thu Nov 01 14:17:33 2018 NETSH: C:\Windows\system32\netsh.exe interface ip delete wins myVPN all

Es gibt noch weitere Alternativen dieser Option:
- ip-win32 ipapi
- ip-win32 dynamic
- ip-win32 manual
- ip-win32 adaptive (Standard)

2) Statische IP zuweisen
--> Netzwerkcenter --> Adaptereinstellungen --> Tap-Adapter --> Eigenschaften --> IPv4 = statisch 10.8.0.2 ...

Hierbei besteht natürlich eine gewisse Gefahr, dass du dem VPN-Client eine statische IP verpasst, die der Server anschließend einem anderen Gerät via DHCP zuweist. Mittels Lösung #1 wird der TAP-Adapter zwar auch auf eine statische IP konfiguriert, aber dies passiert auf Anweisung des Servers und netsh ist am Ende nur das Werkzeug, mit dem die vom VPN-DHCP übergebene IP eingestellt wird, der DHCP weiß aber, dass diese IP dann belegt ist.

Sollte es immer noch nicht funktionieren, wären Screenshots von "ipconfig /all" bzw. "route print" interessant (jeweils mit und ohne VPN). Es ist dann nämlich die Frage ob der TAP-Adapter nicht doch eine gültige IP bekommen hat und es am Ende tatsächlich an den eigentlichen Routen liegt. Ist letzteres der Fall, gäbe es zB auch noch die Möglichkeit, die Routen ähnlich wie Lösung#1 mit anderen Werkzeugen zu erstellen. Dazu gibt es die Option "route-method" wahlweise mit den Parametern adaptive, ipapi oder exe.

TuberPlays · 1. November 2018

Raijin schrieb:
Prüfe zunächst ob der TAP-Adapter im Netzwerkcenter evtl. bereits mit einer falschen IP konfiguriert wurde und somit vielleicht gar nicht auf eine Zuweisung vom DHCP reagiert bzw. diese gar nicht erst anfragt.

Für den TAP-Adapter ist für IPs per DHCP konfiguriert

Raijin schrieb:
--> client.ovpn --> ip-win32 netsh

Damit wird die IP nun explizit mit dem Tool "netsh" zugewiesen. Im Log sieht das dann so aus:

Da bekomme ich gar keine Verbindung zu Stande.

Thu Nov 01 14:49:42 2018 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Thu Nov 01 14:49:42 2018 Windows version 6.2 (Windows 8 or greater) 64bit
Thu Nov 01 14:49:42 2018 library versions: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10
Enter Management Password:
Thu Nov 01 14:49:42 2018 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Thu Nov 01 14:49:42 2018 Need hold release from management interface, waiting...
Thu Nov 01 14:49:43 2018 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Thu Nov 01 14:49:43 2018 MANAGEMENT: CMD 'state on'
Thu Nov 01 14:49:43 2018 MANAGEMENT: CMD 'log all on'
Thu Nov 01 14:49:43 2018 MANAGEMENT: CMD 'echo all on'
Thu Nov 01 14:49:43 2018 MANAGEMENT: CMD 'bytecount 5'
Thu Nov 01 14:49:43 2018 MANAGEMENT: CMD 'hold off'
Thu Nov 01 14:49:43 2018 MANAGEMENT: CMD 'hold release'
Thu Nov 01 14:49:45 2018 MANAGEMENT: CMD 'username "Auth" "#USERNAME#"'
Thu Nov 01 14:49:45 2018 MANAGEMENT: CMD 'password [...]'
Thu Nov 01 14:49:45 2018 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Thu Nov 01 14:49:45 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]#IP-ADRESS#:1194
Thu Nov 01 14:49:45 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Thu Nov 01 14:49:45 2018 Attempting to establish TCP connection with [AF_INET]#IP-ADRESS#:1194 [nonblock]
Thu Nov 01 14:49:45 2018 MANAGEMENT: >STATE:1541080185,TCP_CONNECT,,,,,,
Thu Nov 01 14:49:46 2018 TCP connection established with [AF_INET]#IP-ADRESS#:1194
Thu Nov 01 14:49:46 2018 TCP_CLIENT link local: (not bound)
Thu Nov 01 14:49:46 2018 TCP_CLIENT link remote: [AF_INET]#IP-ADRESS#:1194
Thu Nov 01 14:49:46 2018 MANAGEMENT: >STATE:1541080186,WAIT,,,,,,
Thu Nov 01 14:49:46 2018 MANAGEMENT: >STATE:1541080186,AUTH,,,,,,
Thu Nov 01 14:49:46 2018 TLS: Initial packet from [AF_INET]#IP-ADRESS#:1194, sid=1cef398d 6434932d
Thu Nov 01 14:49:46 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Nov 01 14:49:47 2018 VERIFY OK: depth=1, C=de, L=#STADT#, O=#FIRMENNAME#, CN=#FIRMENNAME# VPN CA, emailAddress=info@#FIRMENNAME#.de
Thu Nov 01 14:49:47 2018 VERIFY OK: depth=0, C=de, L=#STADT#, O=#FIRMENNAME#, CN=fw01, emailAddress=info@#FIRMENNAME#.de
Thu Nov 01 14:49:47 2018 Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Thu Nov 01 14:49:47 2018 [fw01] Peer Connection Initiated with [AF_INET]#IP-ADRESS#:1194
Thu Nov 01 14:49:48 2018 MANAGEMENT: >STATE:1541080188,GET_CONFIG,,,,,,
Thu Nov 01 14:49:48 2018 SENT CONTROL [fw01]: 'PUSH_REQUEST' (status=1)
Thu Nov 01 14:49:48 2018 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.242.2.1,route-gateway 10.242.2.1,topology subnet,ping 10,ping-restart 120,route 192.168.1.0 255.255.255.0,dhcp-option DNS 192.168.1.20,dhcp-option DNS 192.168.1.11,ifconfig 10.242.2.2 255.255.255.0'
Thu Nov 01 14:49:48 2018 OPTIONS IMPORT: timers and/or timeouts modified
Thu Nov 01 14:49:48 2018 OPTIONS IMPORT: --ifconfig/up options modified
Thu Nov 01 14:49:48 2018 OPTIONS IMPORT: route options modified
Thu Nov 01 14:49:48 2018 OPTIONS IMPORT: route-related options modified
Thu Nov 01 14:49:48 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Nov 01 14:49:48 2018 Outgoing Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
Thu Nov 01 14:49:48 2018 Outgoing Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 01 14:49:48 2018 Incoming Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
Thu Nov 01 14:49:48 2018 Incoming Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 01 14:49:48 2018 interactive service msg_channel=592
Thu Nov 01 14:49:48 2018 ROUTE_GATEWAY 192.168.2.1/255.255.255.0 I=8 HWADDR=80:c1:6e:64:db:bd
Thu Nov 01 14:49:48 2018 open_tun
Thu Nov 01 14:49:48 2018 TAP-WIN32 device [Ethernet] opened: \\.\Global\{38E77824-FB8F-478C-82DE-EBBBB4F5EA79}.tap
Thu Nov 01 14:49:48 2018 TAP-Windows Driver Version 9.21
Thu Nov 01 14:49:48 2018 Set TAP-Windows TUN subnet mode network/local/netmask = 10.242.2.0/10.242.2.2/255.255.255.0 [SUCCEEDED]
Thu Nov 01 14:49:48 2018 Successful ARP Flush on interface [9] {38E77824-FB8F-478C-82DE-EBBBB4F5EA79}
Thu Nov 01 14:49:48 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Nov 01 14:49:48 2018 MANAGEMENT: >STATE:1541080188,ASSIGN_IP,,10.242.2.2,,,,
Thu Nov 01 14:49:49 2018 NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address Ethernet static 10.242.2.2 255.255.255.0
Thu Nov 01 14:49:49 2018 ERROR: netsh command failed: returned error code 1
Thu Nov 01 14:49:54 2018 NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address Ethernet static 10.242.2.2 255.255.255.0
Thu Nov 01 14:49:54 2018 ERROR: netsh command failed: returned error code 1
Thu Nov 01 14:49:59 2018 NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address Ethernet static 10.242.2.2 255.255.255.0
Thu Nov 01 14:49:59 2018 ERROR: netsh command failed: returned error code 1
Thu Nov 01 14:50:04 2018 NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address Ethernet static 10.242.2.2 255.255.255.0
Thu Nov 01 14:50:04 2018 ERROR: netsh command failed: returned error code 1
Thu Nov 01 14:50:08 2018 MANAGEMENT: Client disconnected
Thu Nov 01 14:50:08 2018 NETSH: command failed
Thu Nov 01 14:50:08 2018 Exiting due to fatal error

Raijin schrieb:
2) Statische IP zuweisen
--> Netzwerkcenter --> Adaptereinstellungen --> Tap-Adapter --> Eigenschaften --> IPv4 = statisch 10.8.0.2 ...

//Edit:
Auf dem Screenshot steht die falsche Subnetzmaske, aber selbst wenn ich die richtige eintrage, klappts nicht
//Edit Ende

Somit bekomme ich auch dauernde
Thu Nov 01 14:54:19 2018 TAP-Windows Driver Version 9.21
Thu Nov 01 14:54:20 2018 NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address Ethernet dhcp
Thu Nov 01 14:54:20 2018 ERROR: netsh command failed: returned error code 1
Thu Nov 01 14:54:25 2018 NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address Ethernet dhcp
Thu Nov 01 14:54:25 2018 ERROR: netsh command failed: returned error code 1
Thu Nov 01 14:54:30 2018 NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address Ethernet dhcp
Thu Nov 01 14:54:30 2018 ERROR: netsh command failed: returned error code 1
Thu Nov 01 14:54:30 2018 NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address Ethernet dhcp
Thu Nov 01 14:54:30 2018 ERROR: netsh command failed: returned error code 1
Thu Nov 01 14:54:30 2018 MANAGEMENT: Client disconnected
Thu Nov 01 14:54:30 2018 NETSH: command failed
Thu Nov 01 14:54:30 2018 Exiting due to fatal error

Grüße!

Raijin · 1. November 2018

Hast du den Client und/oder die GUI auch als Administrator gestartet? Solche Fehler tauchen üblicherweise auf, wenn OpenVPN mit einem Account ohne ausreichende Berechtigungen gestartet wurde.

TuberPlays · 1. November 2018

Ich hab nun doch eine Funktionierende Aufstellung zusammen bekommen. In der Konfig mit "ip-win32 netsh" die IP beziehen UND Open-VPN als Admin starten.

Ich frag mich nur immer noch, warum ich das ganze Getue nur auf diesem einen Rechner brauche, nachdem ich die Netzwerkkarte getauscht habe..

Grüße und Danke!

Raijin · 1. November 2018

Ich habe (sehr) sporadisch Probleme mit OpenVPN ohne die netsh-Option, da mein OpenVPN-Setup .. .. sagen wir mal .. .. etwas komplexer ist. Bei mir laufen bis zu 4 parallele OpenVPN-Instanzen, eine als Server und 3 als Clients. Das brauche ich für ein abgesichertes Netz sowie diverse Tests im Büro und nicht zuletzt auch 1x für mein privates VPN.

Ab und zu kommt/kommen OpenVPN und/oder Windows aus dem Tritt, wenn ich diverse Reconnects hintereinander mache. Mit netsh scheint es bei mir am wenigsten Probleme zu geben. Normalerweise sollte das aber gerade in einem 08/15 Szenario mit einem einzelnen VPN auch ohne diese Option klappen, mein Setup ist eben deutlich komplexer

Wie dem auch sei, die Einstellung in der client.ovpn tut ja nicht weh und wenn's klappt, dann klappt's eben. Schön, dass wir das noch zum Laufen bekommen haben

TuberPlays · 1. November 2018

Raijin schrieb:
Bei mir laufen bis zu 4 parallele OpenVPN-Instanzen, eine als Server und 3 als Clients

Das konnte ich zum Glück etwas eleganter lösen

Von außen baue ich eine VPN Verbindung zu unserer Sophos im Büro auf, diese wiederum hällt ständige VPN Verbindungen zu unseren "Rundumkunden" und in die geteilten Netze bei uns (Z. B. Produktion, etc). Je nachdem auf welche IP du willst, weiß die "Hauptsophos" wo sie hinrouten muss.

Ist zwar beim ersten mal eine (pardon) Scheißarbeit bis das läuft, aber dann ist es wesentlich einfacher, als zu kucken, wo man eigendlich hin will.

Raijin schrieb:
Schön, dass wir das noch zum Laufen bekommen haben

Joa. Und ich glaube ich werde am Montag dann auch mal bei Sophos nachfragen, wie sowas zu Stande kommt. Ist ja eigentlich nicht üblich.

OpenVPN "kaputt"

Lt. Junior Grade

Workbench Pro

Lt. Commander

Lt. Junior Grade

Workbench Pro

Lt. Junior Grade

Workbench Pro

Lt. Junior Grade

Fleet Admiral

Lt. Junior Grade

Fleet Admiral

Lt. Junior Grade

Fleet Admiral

Lt. Junior Grade

Fleet Admiral

Lt. Junior Grade

Fleet Admiral

Lt. Junior Grade

Fleet Admiral

Lt. Junior Grade

Ähnliche Themen