14
OpenVPN: Zugriff auf Fileserver verzögert
Hallo, ich habe folgendes „Problem“ mit einer VPN Verbindung: ich baue über die OpenVPN Client Software auf einem Win10 Rechner eine Verbindung zu einer OpnSense Firewall mit OpenVPN Server auf. Wenn ich nun den Fileserver über die IP Adresse aufrufen möchte, funktioniert dies manchmal sofort und manchmal dauert es bis zu einer Minute, bis ich die Ordner des Fileservers aufrufen kann. Ein Ping auf den Fileserver funktioniert innerhalb dieser „Wartezeit“ auch nicht. Die VPN Verbindung ist aber aufgebaut. Hat jemand eine Idee woran dies liegt?
Schönes Wochenende
Chris
Schönes Wochenende
Chris
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: 596273
Url: https://administrator.de/contentid/596273
Ausgedruckt am: 18.11.2024 um 14:11 Uhr
14 Kommentare
Neuester Kommentar
Moin Chris,
> Hat jemand eine Idee woran dies liegt?
Na ja, das Problem ist eher, dass mit den von dir bereitgestellten Informationen eher hunderte Ideen in Frage kommen. 🙃
Fürs erste riecht es für mich nach einem temporären Routingproblem.
Ich würde dir daher als nächstes mal das folgende Empfehlen.
Mache einen tracert auf die IP des Fileservers, wenn die Verbindung funktioniert und bitte einmal wenn diese nicht funktioniert und schau anschliessend nach, ob die Datenpakete denselben Weg nehmen (möchten). Ausserdem siehst du mit tracert viel genauer, an welchem Hop die Verbindung gegen die Wand fährt.
Mit den durch tracert gewonnen Informationen, können wir dir hier ferner viel gezielter helfen.
Grüsse aus BaWü
Alex
> Hat jemand eine Idee woran dies liegt?
Na ja, das Problem ist eher, dass mit den von dir bereitgestellten Informationen eher hunderte Ideen in Frage kommen. 🙃
Fürs erste riecht es für mich nach einem temporären Routingproblem.
Ich würde dir daher als nächstes mal das folgende Empfehlen.
Mache einen tracert auf die IP des Fileservers, wenn die Verbindung funktioniert und bitte einmal wenn diese nicht funktioniert und schau anschliessend nach, ob die Datenpakete denselben Weg nehmen (möchten). Ausserdem siehst du mit tracert viel genauer, an welchem Hop die Verbindung gegen die Wand fährt.
Mit den durch tracert gewonnen Informationen, können wir dir hier ferner viel gezielter helfen.
Grüsse aus BaWü
Alex
In der Tat... Ohne zumindest deine beiden Konfig Dateien von Server und Client ist ein Troubleshooting nur durch freies Raten wenig zielführend.
Grundlegende Infos zu dem Thema OpenVPN findest du immer im Merkzettel
Merkzettel: VPN Installation mit OpenVPN
Grundlegende Infos zu dem Thema OpenVPN findest du immer im Merkzettel
Merkzettel: VPN Installation mit OpenVPN
Hallo.
Nicht zu verachten ist auch die Art der Verbindung mit welcher dein Win10 PC mit dem Internet kommuniziert.
Ist es ein mobiler Hotspot vom Smartphone aus oder WLAN? Dann verwundert es nicht, dass die Geschwindigkeiten und Reaktionszeiten stark variieren. Eine LAN Verbindung ist immer das Mittel um zumindest irgendwelche Leitungs-Interferenzen auszuschließen.
Gruß
Radiogugu
Nicht zu verachten ist auch die Art der Verbindung mit welcher dein Win10 PC mit dem Internet kommuniziert.
Ist es ein mobiler Hotspot vom Smartphone aus oder WLAN? Dann verwundert es nicht, dass die Geschwindigkeiten und Reaktionszeiten stark variieren. Eine LAN Verbindung ist immer das Mittel um zumindest irgendwelche Leitungs-Interferenzen auszuschließen.
Gruß
Radiogugu
Moin zusammen,
vielen Dank für Eure Tipps
Ich habe es jetzt mal über tracert probiert, hier die Ergebnisse:
1. Versuch:
Routenverfolgung zu 192.168.123.100 über maximal 30 Hops
1 1 ms 1 ms 2 ms 192.168.0.1 --> lokaler Router bei mir zuhause
2 62.155.246.XXX meldet: Zielnetz nicht erreichbar.
2. Versuch etwas später:
Routenverfolgung zu 192.168.123.100 über maximal 30 Hops
1 1 ms 1 ms 1 ms 192.168.0.1
2 10 ms 10 ms 8 ms server.XXX.local [192.168.123.100]
3. Versuch:
Routenverfolgung zu server.XXX.local [192.168.123.100]
über maximal 30 Hops:
1 8 ms 7 ms 8 ms 10.10.20.1
2 9 ms 9 ms 8 ms server.XXX.local [192.168.123.100]
@radiogugu: Der Client ist über WLAN und eine 50MBit Leitung angebunden. Der Server hat eine Internet Anbindung mit ca. 600Mbit.
vielen Dank für Eure Tipps
Ich habe es jetzt mal über tracert probiert, hier die Ergebnisse:
1. Versuch:
Routenverfolgung zu 192.168.123.100 über maximal 30 Hops
1 1 ms 1 ms 2 ms 192.168.0.1 --> lokaler Router bei mir zuhause
2 62.155.246.XXX meldet: Zielnetz nicht erreichbar.
2. Versuch etwas später:
Routenverfolgung zu 192.168.123.100 über maximal 30 Hops
1 1 ms 1 ms 1 ms 192.168.0.1
2 10 ms 10 ms 8 ms server.XXX.local [192.168.123.100]
3. Versuch:
Routenverfolgung zu server.XXX.local [192.168.123.100]
über maximal 30 Hops:
1 8 ms 7 ms 8 ms 10.10.20.1
2 9 ms 9 ms 8 ms server.XXX.local [192.168.123.100]
@radiogugu: Der Client ist über WLAN und eine 50MBit Leitung angebunden. Der Server hat eine Internet Anbindung mit ca. 600Mbit.
Naja - zeigst du denn immer dasselbe an? Es ist ja nicht so das dort nur bunte Bilder kommen - es werden ja auch Meta-Infos beim Öffnen schon geladen. Und da ist es natürlich grad via VPN ein Unterschied ob du nun nur 1 - 2 Ordner im Explorer anzeigen lassen willst - oder ob da schon 100.000 Dateien im Ordner liegen.
Wenn ich z.B. nur die oberste Ebene mir anzeigen lasse geht das via OpenVPN noch recht schnell - sind bereits div. Ordner "ausgeklappt" (Mac) dann dauert es entsprechend länger...
Wenn ich z.B. nur die oberste Ebene mir anzeigen lasse geht das via OpenVPN noch recht schnell - sind bereits div. Ordner "ausgeklappt" (Mac) dann dauert es entsprechend länger...
Da die Konfig Dateien und ggf. auch der Output der Routing Tabelle fehlen weiterhin raten wir hier fröhlich ala Kristallkugel weiter. 
Knackpunkt ist oft auch die lokale Winblows Firewall oder ggf. Externe Virenscanner ala Kaspersky und Co. sofern der Client Winblows basiert ist. Aber auch da fehlt leider die entspr. Info.
Knackpunkt ist oft auch die lokale Winblows Firewall oder ggf. Externe Virenscanner ala Kaspersky und Co. sofern der Client Winblows basiert ist. Aber auch da fehlt leider die entspr. Info.
Moin Aqui,
Warum nur "ala", du musst nur eine haben, dann kannst du diese auch direkt befragen. 🤪
Meine sagt mir gerade, dass Chris Problem bereits an seinem Client liegt, das eine mal jagt er die Anfrage über das lokale Gateway "192.168.0.1" und das andere Mal geht die Anfrage sauber über das VPN-Gateway "10.10.20.1" raus.
@ Chris
Dann gehen wir mal in die nächste Runde.
Führe bitte ein "route print" auf deinem Rechner aus wenn die Verbindung nicht funktioniert und einmal dasselbe sobald diese geht.
Anschliessend bitte die IPv4-Routingtabelle beider Ausgaben inkl. Ständige Routen posten, danke.
Grüsse aus BaWü
Alex
raten wir hier fröhlich ala Kristallkugel weiter.
Warum nur "ala", du musst nur eine haben, dann kannst du diese auch direkt befragen. 🤪
Meine sagt mir gerade, dass Chris Problem bereits an seinem Client liegt, das eine mal jagt er die Anfrage über das lokale Gateway "192.168.0.1" und das andere Mal geht die Anfrage sauber über das VPN-Gateway "10.10.20.1" raus.
@ Chris
Dann gehen wir mal in die nächste Runde.
Führe bitte ein "route print" auf deinem Rechner aus wenn die Verbindung nicht funktioniert und einmal dasselbe sobald diese geht.
Anschliessend bitte die IPv4-Routingtabelle beider Ausgaben inkl. Ständige Routen posten, danke.
Grüsse aus BaWü
Alex
Hallo zusammen,
sorry für die späte Rückmeldung. Hier einige Infos zu dem System:
Client: Win10 Pro; Virenscanner Kaspersky (hatte ich zum Testen deaktiviert, ohne erfolg)
Route Print:
Funktioniert:
IPv4-Routentabelle
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.75 25
10.10.20.0 255.255.255.0 Auf Verbindung 10.10.20.2 257
10.10.20.2 255.255.255.255 Auf Verbindung 10.10.20.2 257
10.10.20.255 255.255.255.255 Auf Verbindung 10.10.20.2 257
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
192.168.0.0 255.255.255.0 Auf Verbindung 192.168.0.75 281
192.168.0.75 255.255.255.255 Auf Verbindung 192.168.0.75 281
192.168.0.255 255.255.255.255 Auf Verbindung 192.168.0.75 281
192.168.123.0 255.255.255.0 10.10.20.1 10.10.20.2 257
217.73.XXX.XX 255.255.255.255 192.168.0.1 192.168.0.75 281
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 10.10.20.2 257
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.0.75 281
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 10.10.20.2 257
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.0.75 281
Ständige Routen:
Keine
Funktioniert Nicht:
IPv4-Routentabelle
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.75 25
10.10.20.0 255.255.255.0 Auf Verbindung 10.10.20.2 257
10.10.20.2 255.255.255.255 Auf Verbindung 10.10.20.2 257
10.10.20.255 255.255.255.255 Auf Verbindung 10.10.20.2 257
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
192.168.0.0 255.255.255.0 Auf Verbindung 192.168.0.75 281
192.168.0.75 255.255.255.255 Auf Verbindung 192.168.0.75 281
192.168.0.255 255.255.255.255 Auf Verbindung 192.168.0.75 281
192.168.123.0 255.255.255.0 10.10.20.1 10.10.20.2 257
217.73.XXX.XX 255.255.255.255 192.168.0.1 192.168.0.75 281
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 10.10.20.2 257
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.0.75 281
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 10.10.20.2 257
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.0.75 281
Ständige Routen:
Keine
OpenVPN Client Konfig File:
dev tun
persist-tun
persist-key
cipher AES-256-CBC
auth SHA512
client
resolv-retry infinite
remote 217.73.XXX.XX 1194 udp
lport 0
auth-user-pass
comp-lzo no
OpenVPN Server Konfig:
Servermodus Remotezugriff ( SSL/TLS + Benutzerauthentifizierung )
Backend Authentifizierung LDAP XXX/Lokale Datenbank
Lokale Gruppe erzwingen
(keiner)
Protokoll UDP
Gerätemodus tun
Schnittstelle WAN
Lokaler Port 1194
Kryptografische Einstellungen TLS Authentifikation
Peer-Zertifizierungsstelle XXXXXX
Peerzertifikatsrückrufliste None
Serverzertifikate OpenVPN Server Zertifikat (XXX) *In Use
DH Parameterlänge 4096 bit
Verschlüsselungsalgorithmus AES-256-CBC (256 bit key, 128 bit block)
Authentifizierungs-Digestalgorithmus SHA512 (512-bit)
Hardwarekryptografie Intel RDRAND engine - RAND
Zertifikatstiefe Eins (Client + Server)
Strenge Benutzer/CN-Prüfung aus
IPv4 Tunnelnetzwerk 10.10.20.0/24
IPv6 Tunnelnetzwerk
Weiterleitungs Gateway
Lokales IPv4-Netzwerk 192.168.123.0/24
Lokales IPv6-Netzwerk
Fernes IPv4-Netzwerk
Fernes IPv6-Netzwerk
Konkurrierende Verbindungen
Komprimierung Deaktiviert - keine Kompression
Typ des Dienstes aus
Inter-Client-Kommunikation ein
Doppelte Verbindungen ein
IPv6 deaktivieren ein
Dynamische IP ein
Adresspool ein
Netzstruktur ein
DNS Standard Domain aus
DNS Server ein
Server #1:
192.168.123.103
Server #2:
8.8.8.8
Server #3:
Server #4:
Erzwinge DNS-Cache Aktualisierung aus
NTP Server aus
NetBIOS Optionen aus
Clientverwaltungsport aus
Den Common-Name verwenden aus
Erweiterte Konfiguration
Erweitert
Ausführlichkeitslevel 1 (standard)
Zeit bis zur Neubestimmung
Force CSO Login Matching aus
sorry für die späte Rückmeldung. Hier einige Infos zu dem System:
Client: Win10 Pro; Virenscanner Kaspersky (hatte ich zum Testen deaktiviert, ohne erfolg)
Route Print:
Funktioniert:
IPv4-Routentabelle
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.75 25
10.10.20.0 255.255.255.0 Auf Verbindung 10.10.20.2 257
10.10.20.2 255.255.255.255 Auf Verbindung 10.10.20.2 257
10.10.20.255 255.255.255.255 Auf Verbindung 10.10.20.2 257
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
192.168.0.0 255.255.255.0 Auf Verbindung 192.168.0.75 281
192.168.0.75 255.255.255.255 Auf Verbindung 192.168.0.75 281
192.168.0.255 255.255.255.255 Auf Verbindung 192.168.0.75 281
192.168.123.0 255.255.255.0 10.10.20.1 10.10.20.2 257
217.73.XXX.XX 255.255.255.255 192.168.0.1 192.168.0.75 281
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 10.10.20.2 257
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.0.75 281
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 10.10.20.2 257
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.0.75 281
Ständige Routen:
Keine
Funktioniert Nicht:
IPv4-Routentabelle
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.75 25
10.10.20.0 255.255.255.0 Auf Verbindung 10.10.20.2 257
10.10.20.2 255.255.255.255 Auf Verbindung 10.10.20.2 257
10.10.20.255 255.255.255.255 Auf Verbindung 10.10.20.2 257
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
192.168.0.0 255.255.255.0 Auf Verbindung 192.168.0.75 281
192.168.0.75 255.255.255.255 Auf Verbindung 192.168.0.75 281
192.168.0.255 255.255.255.255 Auf Verbindung 192.168.0.75 281
192.168.123.0 255.255.255.0 10.10.20.1 10.10.20.2 257
217.73.XXX.XX 255.255.255.255 192.168.0.1 192.168.0.75 281
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 10.10.20.2 257
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.0.75 281
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 10.10.20.2 257
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.0.75 281
Ständige Routen:
Keine
OpenVPN Client Konfig File:
dev tun
persist-tun
persist-key
cipher AES-256-CBC
auth SHA512
client
resolv-retry infinite
remote 217.73.XXX.XX 1194 udp
lport 0
auth-user-pass
comp-lzo no
OpenVPN Server Konfig:
Servermodus Remotezugriff ( SSL/TLS + Benutzerauthentifizierung )
Backend Authentifizierung LDAP XXX/Lokale Datenbank
Lokale Gruppe erzwingen
(keiner)
Protokoll UDP
Gerätemodus tun
Schnittstelle WAN
Lokaler Port 1194
Kryptografische Einstellungen TLS Authentifikation
Peer-Zertifizierungsstelle XXXXXX
Peerzertifikatsrückrufliste None
Serverzertifikate OpenVPN Server Zertifikat (XXX) *In Use
DH Parameterlänge 4096 bit
Verschlüsselungsalgorithmus AES-256-CBC (256 bit key, 128 bit block)
Authentifizierungs-Digestalgorithmus SHA512 (512-bit)
Hardwarekryptografie Intel RDRAND engine - RAND
Zertifikatstiefe Eins (Client + Server)
Strenge Benutzer/CN-Prüfung aus
IPv4 Tunnelnetzwerk 10.10.20.0/24
IPv6 Tunnelnetzwerk
Weiterleitungs Gateway
Lokales IPv4-Netzwerk 192.168.123.0/24
Lokales IPv6-Netzwerk
Fernes IPv4-Netzwerk
Fernes IPv6-Netzwerk
Konkurrierende Verbindungen
Komprimierung Deaktiviert - keine Kompression
Typ des Dienstes aus
Inter-Client-Kommunikation ein
Doppelte Verbindungen ein
IPv6 deaktivieren ein
Dynamische IP ein
Adresspool ein
Netzstruktur ein
DNS Standard Domain aus
DNS Server ein
Server #1:
192.168.123.103
Server #2:
8.8.8.8
Server #3:
Server #4:
Erzwinge DNS-Cache Aktualisierung aus
NTP Server aus
NetBIOS Optionen aus
Clientverwaltungsport aus
Den Common-Name verwenden aus
Erweiterte Konfiguration
Erweitert
Ausführlichkeitslevel 1 (standard)
Zeit bis zur Neubestimmung
Force CSO Login Matching aus
Die IP Adresse in der Client Config stimmt auch nach, wie vor? Sieht wie eine dynamische Consumer IP aus. Ist sichergestellt, dass diese sich nicht ändert?
Gruß
Radiogugu
Gruß
Radiogugu
Die Client OVPN Konfig ist ja noch OK aber die Server Konfig wirr und unverständlich. Diese ist aber die Relevantere von beiden Seiten !
Insbesondere die Routing Einstellung ob push route oder Gateway redirect ist daraus nicht ersichtlich.
Am besten also mit PuTTY auf den Server gehen und poer SSH Shell die OVPN Konfig Datei auslesen.
Dann auch noch 8.8.8.8 als DNS zu konfigurieren machen heutzutage nur noch Dummies. Jedermann weiss das Google damit Profile über Surf- und Internet Gewohnheiten erstellt und die mit 3ten vermarktet. Wer sich so ausspionieren lässt hat ja eh schon ganz andere Probleme. Sinnvoller wäre eine datenschutzfreundlichere Alternative: https://www.heise.de/newsticker/meldung/Quad9-Datenschutzfreundliche-Alt ...
Insbesondere die Routing Einstellung ob push route oder Gateway redirect ist daraus nicht ersichtlich.
Am besten also mit PuTTY auf den Server gehen und poer SSH Shell die OVPN Konfig Datei auslesen.
Dann auch noch 8.8.8.8 als DNS zu konfigurieren machen heutzutage nur noch Dummies. Jedermann weiss das Google damit Profile über Surf- und Internet Gewohnheiten erstellt und die mit 3ten vermarktet. Wer sich so ausspionieren lässt hat ja eh schon ganz andere Probleme. Sinnvoller wäre eine datenschutzfreundlichere Alternative: https://www.heise.de/newsticker/meldung/Quad9-Datenschutzfreundliche-Alt ...
Guten Morgen, wenn Du die 217.73.XXX.XX meinst, die ist fest.
Gruß Christoph
Gruß Christoph
Hallo,
DNS habe ich geändert und dabei auch gleich die Server.conf ausgelesen (Gateway redirect ist nicht aktiviert):
dev ovpns1
verb 1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
auth SHA512
up /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup
down /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkdown
local 217.73.XXX.XX
engine rdrand
client-disconnect "/usr/local/etc/inc/plugins.inc.d/openvpn/attributes.sh server1"
tls-server
server 10.10.20.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/1
username-as-common-name
auth-user-pass-verify "/usr/local/etc/inc/plugins.inc.d/openvpn/ovpn_auth_verify user 'XXX,Local Database' 'false' 'server1'" via-env
tls-verify "/usr/local/etc/inc/plugins.inc.d/openvpn/ovpn_auth_verify tls 'XXX' 1"
lport 1194
management /var/etc/openvpn/server1.sock unix
push "route 192.168.123.0 255.255.255.0"
push "dhcp-option DNS 192.168.123.103"
push "dhcp-option DNS 9.9.9.9"
push "register-dns"
client-to-client
duplicate-cn
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /usr/local/etc/dh-parameters.4096.sample
tls-auth /var/etc/openvpn/server1.tls-auth 0
comp-lzo no
persist-remote-ip
float
topology subnet
DNS habe ich geändert und dabei auch gleich die Server.conf ausgelesen (Gateway redirect ist nicht aktiviert):
dev ovpns1
verb 1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
auth SHA512
up /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup
down /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkdown
local 217.73.XXX.XX
engine rdrand
client-disconnect "/usr/local/etc/inc/plugins.inc.d/openvpn/attributes.sh server1"
tls-server
server 10.10.20.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/1
username-as-common-name
auth-user-pass-verify "/usr/local/etc/inc/plugins.inc.d/openvpn/ovpn_auth_verify user 'XXX,Local Database' 'false' 'server1'" via-env
tls-verify "/usr/local/etc/inc/plugins.inc.d/openvpn/ovpn_auth_verify tls 'XXX' 1"
lport 1194
management /var/etc/openvpn/server1.sock unix
push "route 192.168.123.0 255.255.255.0"
push "dhcp-option DNS 192.168.123.103"
push "dhcp-option DNS 9.9.9.9"
push "register-dns"
client-to-client
duplicate-cn
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /usr/local/etc/dh-parameters.4096.sample
tls-auth /var/etc/openvpn/server1.tls-auth 0
comp-lzo no
persist-remote-ip
float
topology subnet
Moin Chris,
ich erkenne jetzt an deiner Konfiguration keinen Fehler.
Anhand deiner Tracert Ergebnisse, sieht es jedoch danach aus, als ob die VPN Verbindung deinerseits (Clientseitig) das Problem hat.
Hast du die Möglichkeit, die Einwahl mal von einem anderen Internetanschluss durchzuführen (möglichst anderen Provider)?
Wir administrieren einige VPN-Gateways bei den Kunden und ich kenne zu genüge Fälle, wo genau dieses Problem am Anschluss (Provider) gelegen ist. Erst neulich hat ein wütender Account-Manager versucht mir und einem internen Kundenadministrator einen Einlauf zu verpassen, weil er ständig Probleme mit seinem VPN Zugang hatte. Am Vortag konnte er seiner Aussage nach absolut nicht arbeiten, zu unserem Glück war sowohl der Admin vom HomeOffice den ganzen Tag ohne Probleme über das selbe Gateway verbunden, als auch der GF und auch ich war mehrere Stunden bei dem Kunden online.
Da der Account-Manager ein gutes LTE Signal hatte, gaben wir Ihm den Tipp, er soll mal den nächsten Tag einen Hotspot über sein Smartphone aufbauen und testweise mal über dieses arbeiten. Am nächsten Tag kam das folgende Feedback: "👍👍👍, den ganzen Tag keine Probleme".
Grüsse aus BaWü
Alex
ich erkenne jetzt an deiner Konfiguration keinen Fehler.
Anhand deiner Tracert Ergebnisse, sieht es jedoch danach aus, als ob die VPN Verbindung deinerseits (Clientseitig) das Problem hat.
Hast du die Möglichkeit, die Einwahl mal von einem anderen Internetanschluss durchzuführen (möglichst anderen Provider)?
Wir administrieren einige VPN-Gateways bei den Kunden und ich kenne zu genüge Fälle, wo genau dieses Problem am Anschluss (Provider) gelegen ist. Erst neulich hat ein wütender Account-Manager versucht mir und einem internen Kundenadministrator einen Einlauf zu verpassen, weil er ständig Probleme mit seinem VPN Zugang hatte. Am Vortag konnte er seiner Aussage nach absolut nicht arbeiten, zu unserem Glück war sowohl der Admin vom HomeOffice den ganzen Tag ohne Probleme über das selbe Gateway verbunden, als auch der GF und auch ich war mehrere Stunden bei dem Kunden online.
Da der Account-Manager ein gutes LTE Signal hatte, gaben wir Ihm den Tipp, er soll mal den nächsten Tag einen Hotspot über sein Smartphone aufbauen und testweise mal über dieses arbeiten. Am nächsten Tag kam das folgende Feedback: "👍👍👍, den ganzen Tag keine Probleme".
Grüsse aus BaWü
Alex
In der Tat. An der OVPN Konfig kann es nicht liegen. Das ist eine klassische Split Tunneling Konfig.
Es bleibt dann ggf. nur noch ein DNS Problem, da der lokale DNS Server 192.168.123.103 bei aktivem VPN der primäre DNS ist. Kann der mal etwas nicht auflösen kommt es zu solchen Wartezeiten und Timeouts bevor der 2te verwendet wird.
Sollte es das nicht sein bleiben dann eigentlich nur noch temporäre Ausfälle auf der unter dem VPN liegenden Protokoll Infrastruktur.
Es bleibt dann ggf. nur noch ein DNS Problem, da der lokale DNS Server 192.168.123.103 bei aktivem VPN der primäre DNS ist. Kann der mal etwas nicht auflösen kommt es zu solchen Wartezeiten und Timeouts bevor der 2te verwendet wird.
Sollte es das nicht sein bleiben dann eigentlich nur noch temporäre Ausfälle auf der unter dem VPN liegenden Protokoll Infrastruktur.
