OpenVPN-Probleme Windows 10-Clients

baumhof · 2. Januar 2018 um 17:01

Hallo alle zusammen,

heute war jemand an der Hotline mit dem selben Problem:
Windows 10
openVPN wird als admin ausgeführt
Verbindung klappt, man kann auch das Home verbinden, aber man kommt auf
keine Webseiten.
Ich hab auch auf die mtu getippt: vor allem weil im log unterschiedliche
mtu für lokal und remote drin standen: hat aber nix gebracht.
Namensauflösung funktioniert: wenn man als
ping server
oder
ping ipfire
macht, dann kommt der ping von 10.16.1.1 bzw. 10.16.1.254 zurück.
Aber man kann keien Webseite aufrufen.

Die config sieht so aus:

#OpenVPN Server conf
tls-client
client
dev tun
proto udp
tun-mtu 1400
remote meine-schule.de 1194
pkcs12 meinusername.p12
cipher BF-CBC
comp-lzo
verb 3
ns-cert-type server

Auf dem IPFire ist unter advanced Options das redir Gateway 1 gesetzt:
aber auch ohne bleibt das Problem wohl.
Was mich wunderte war, dass das lokale Gateway auf 192.168.2.1 blieb und
bei 172.16.18.x kein Default Gateway gesetzt wurde.

Wie muss der Eintrag für mtu-dicover lauten?
Wurde das Problem bei euch behoben?
Welche oVPN Version habt ihr auf dem Client?

LG

Holger

alois · 2. Januar 2018 um 17:45

Hallo,

ich verwende die im Bild gezeigten Versionen und es funktioniert.

openvpn_version

Die OpenVPN-Version

Welche Version benutzen die, bei denen es nicht funktioniert.

Gruß

Alois

baumhof · 2. Januar 2018 um 18:18

Hallo Alois,

openvpn_version2
https://ask.linuxmuster.net/uploads/default/original/1X/e487535778bf7b9209820cf6a1f08b77fc32347f.png

Welche Version benutzen die, bei denen es nicht funktioniert.

weiß ich nicht.
Er meinte, er hat schon verschiedene versucht.

Ich hab ihm gesagt, er soll hier nachfragen und auch logfiles posten.

LG

Holger

Uli · 4. Januar 2018 um 13:42

Hallo Holger und Alois,
ich hab das oben beschriebene OpenVPN-Problem letzte Woche versucht mit Holger im Support zu klären … wir verwenden auch Version 2.3.18, ebenso die portable Version 2.1.1
Gruß
Uli

baumhof · 4. Januar 2018 um 15:16

Hallo Uli,

wir verwenden auch Version 2.3.18, ebenso die portable Version 2.1.1 …
anbei die entsprechenden Logfiles.

… logfiles hingen keine dran …

LG

Holger

Uli · 4. Januar 2018 um 16:00

… die Logfiles:

2.3.18.txt (5,9 KB)

2.1.1.txt (4,8 KB)

Gruß Uli

morpweb · 6. Januar 2018 um 08:52

Hallo zusammen,

einen offensichtlichen Fehler in der Konfiguration scheint ja niemand zu finden. Funktionieren denn der/die betroffenen Accounts an einem anderen „funktionierenden“ Rechner. Falls ja, wäre das Problem wohl ein Problem des Windows10 Rechners, das schwer zu finden sein dürfte (kaputter Netzwerkstack, lokale Proxies diverser Virenscanner … ). Bei mir funktionieren alle Windows10 OpenVPN-Clients auch problemlos.

Der einzige Punkt, den ich nicht ganz nachvollziehen kann, ist die Route:

C:\WINDOWS\system32\route.exe ADD 172.16.18.1 MASK 255.255.255.255 172.16.18.5

Die VPN-Tunnel sind aus meiner Sicht „Punkt zu Punkt“ Verbindungen und die Route über das Interface auf der Firewall sollte ausreichend sein, um den Tunnel zu verlassen.

Grüße
Bertram

PS: Bei Gelegenheit und auch wenn es mit Arbeit an den Clients verbunden ist, ist es bestimmt eine gute Idee, die symmetrische Verschlüsselung von „BF-CBC“ auf z.B. „AES-CBC“ und den Hashing-Algorithmus auf SHA2 zu „verbessern“.

morpweb · 6. Januar 2018 um 09:43

Hallo zusammen,

wenn Ihr etwas genauer schauen wollt, könnt Ihr auf der Firewall mittels z.B. tcpdump mitsniffern, ob die Pakete überhaupt durch den Tunnel gehen.

Schritt 1: tcpdump installieren

[root@ipfire ~]# pakfire install tcpdump

Schritt 2: Schauen, z.B. auf 10.16.1.1 Port 443

tcpdump -nli tun0 host 10.16.1.1 and tcp dst port 443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
10:40:14.291230 IP 172.16.18.6.54096 > 10.16.1.1.443: Flags [S], seq 3391274490, win 27200, options [mss 1352,sackOK,TS val 2715836098 ecr 0,nop,wscale 7], length 0
10:40:14.310750 IP 172.16.18.6.54096 > 10.16.1.1.443: Flags [.], ack 206601096, win 213, options [nop,nop,TS val 2715836103 ecr 345657975], length 0
10:40:14.311929 IP 172.16.18.6.54096 > 10.16.1.1.443: Flags [P.], seq 0:200, ack 1, win 213, options [nop,nop,TS val 2715836103 ecr 345657975], length 200
10:40:14.375643 IP 172.16.18.6.54096 > 10.16.1.1.443: Flags [.], ack 1026, win 229, options [nop,nop,TS val 2715836119 ecr 345657987], length 0
10:40:14.381055 IP 172.16.18.6.54096 > 10.16.1.1.443: Flags [P.], seq 200:326, ack 1026, win 229, options [nop,nop,TS val 2715836121 ecr 345657987], length 126
10:40:14.384518 IP 172.16.18.6.54096 > 10.16.1.1.443: Flags [P.], seq 326:804, ack 1026, win 229, options [nop,nop,TS val 2715836121 ecr 345657987], length 478
10:40:14.407971 IP 172.16.18.6.54096 > 10.16.1.1.443: Flags [.], ack 1525, win 261, options [nop,nop,TS val 2715836127 ecr 345657997], length 0

Kurze Anleitung z.B. hier http://packetlife.net/media/library/12/tcpdump.pdf

Grüße
Bertram

alois · 6. Januar 2018 um 12:06

Hallo,

Die Maske MASK 255.255.255.255 halte ich für falsch. Sie müsste m.E. MASK 255.255.255.0 lauten.

Gruß

Alois

baumhof · 6. Januar 2018 um 22:08

Hallo,

Die Maske MASK 255.255.255.255 halte ich für falsch. Sie müsste m.E.
MASK 255.255.255.0 lauten.

weiß jemand, wo man die einstellt?

Kann jemand mal bei einem seiner oVPN Verbindungen im log nachschauen,
welche Netzwerkmaske da verwendet wird?

LG

Holger

morpweb · 7. Januar 2018 um 07:41

Hallo,

die Subnetzmaske ist meiner Ansicht nach ok, da es sich um eine “Host-Route” handelt. Meiner Ansicht nach ist der Eintrag nur überflüssig, da für die Clients bei einer Verbindung die IP der Firewall massgebend ist, z.B.

 tun0      Link encap:UNSPEC  Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet Adresse:172.16.18.6  P-z-P:172.16.18.5  Maske:255.255.255.255
          UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1400  Metrik:1
          RX-Pakete:4 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:4 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:100 
          RX-Bytes:1456 (1.4 KB)  TX-Bytes:271 (271.0 B)

In diesem Fall lauet sie 172.16.18.5.

10.16.0.0       172.16.18.5     255.240.0.0     UG    50     0        0 tun0
172.16.18.5     0.0.0.0         255.255.255.255 UH    50     0        0 tun0

Ich würde raten, dass der Eintrag unter Dienste -> OpenVPN -> Erweiterte Server-Optionen zu finden ist.

Bildschirmfoto

Grüße

baumhof · 7. Januar 2018 um 10:44

Hallo Bertram,

In diesem Fall lauet sie 172.16.18.5.

10.16.0.0 172.16.18.5 255.240.0.0 UG 50 0 0 tun0 172.16.18.5 0.0.0.0
255.255.255.255 UH 50 0 0 tun0 |

Ich würde raten, dass der Eintrag unter Dienste → OpenVPN → Erweiterte
Server-Optionen zu finden ist.

was genau soll in das Feld eingetragen werden?

LG

Holger

morpweb · 7. Januar 2018 um 13:44

Hallo Holger,

Das Feld kann leer bleiben.

Habe mir die Sache gerade noch einmal genauer angeschaut. Die Zeile

ist normal. Hatte bei mir am Client die Routen manuell angepasst und es vergessen. Die OpenVPN-Config ist auf der Firewall unter /var/ipfire/ovpn/server.conf zu finden. Dort gibt es die Zeile push "redirect-gateway def1", die für das Setzen der Route auf dem Client verantwortlich ist und diesen „dreifachen Eintrag“ erzeugt. Die wichtige Zeile ist m.E. nur die Erste …

0.0.0.0         172.16.18.5     0.0.0.0         UG    50     0        0 tun0
172.16.18.1     172.16.18.5     255.255.255.255 UGH   50     0        0 tun0
172.16.18.5     0.0.0.0         255.255.255.255 UH    50     0        0 tun0

Unter Windows offensichtlich:

Thu Jan 04 13:49:48 2018 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 172.16.18.5
Thu Jan 04 13:49:48 2018 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 172.16.18.5
Thu Jan 04 13:49:48 2018 C:\WINDOWS\system32\route.exe ADD 172.16.18.1 MASK 255.255.255.255 172.16.18.5

Die 172.16.18.1 ist die IP des tun0 Interfaces auf der Firewall. Ich bitte die Verwirrung zu entschuldigen …

Grüße
Bertram

PS: Das Log des OpenVPN-Servers ist übrigens auf der Firewall in der /var/log/messages zu finden, also z.B. ein tail -f /var/log/messages |grep openvpnserver

martini412 · 2. August 2019 um 11:40

Hallo,
wir haben folgendes Problem mit Win10 Clients:

Verbindung kann hergestellt werden (als Administrator gestartet)
Beim Verbinden des Home als Netzlaufwerk gibt es ein Problem mit smb:

Das Netzlaufwerk konnte nicht verbunden werden, da der folgende Fehler aufgetreten ist: Sie können keine Verbindung mit der Dateifreigabe herstellen, weil sie unsicher ist. Diese Freigabe erfordert das veraltete SMB1-Protokoll, das unsicher ist und Ihr System angreifbar machen könnte. Ihr System erfordert mindestens SMB2. Weitere Informationen dazu, wie Sie das Problem beheben, finden Sie unter SMBv1 is not installed by default in Windows 10 version 1709, Windows Server version 1709 and later versions | Microsoft Learn.

Ist das jemand schon begenet?

VG Jürgen

jochen · 2. August 2019 um 12:40

Hallo Jürgen,

versuch mal, bei den Windows Features den SMB 1.0 / CIFS Client zu aktivieren.

Viele Grüße,
Jochen