7
OpenVPN Verbindung klappt, bricht aber bei tatsächlichem Kopieren stets ab.
Hallo,
wenn ich aus Explorer versuche auf den OVPN Server zuzugreifen, klappt die Verbindung ohne Probleme, ich kann auf die Verzeichnisse zugreifen. Beim Kopieren auf den lokalen PC kommt die folgende Meldung:
Der Server läuft auf pfSense und hat bisher ohne Probleme gearbeitet... Es gab immer wieder Kleinigkeiten, die aber bei Serverneustart eliminiert werden konnten.
Da wir auf dem Server nichts umkonfiguriert haben, haben wir keine Ahnung. Die einzige Änderung ist, dass wir von dem Internetprovider eine eine neue fixe IP haben. Der VPN Config verwendet jetzt also diese IP und nicht die usprüngliche Domain.
Hat jemand eine Idee, wo alles die Probleme sein können?
Das Problem tritt nur im Windows Explorer auf. Wenn ich im Browser z. B. aufs NAS zugreifen möchte gibt es keine Probleme. Auch im WE klappte es zwei kleine Dateien zu übertragen. Die Verbindung ist also da ist aber extrem schlecht und es tritt eine Art Time-Out auf.
Im Standort 1 ist der pfSense hinter einem Fritzbox 6360, wo LAN2 auf Bridge gestellt ist und leitet Traffic auf die FW um.
Für ca. 10-15 Sekunde erreicht der Upload ca. 70-90KB / Sek (statt 300-400KB / Sec. --> Wir haben 5Mbit/s Upload) und dann geht die Verbindung zu NAS flöten.
Gr. I.
wenn ich aus Explorer versuche auf den OVPN Server zuzugreifen, klappt die Verbindung ohne Probleme, ich kann auf die Verzeichnisse zugreifen. Beim Kopieren auf den lokalen PC kommt die folgende Meldung:
Der Server läuft auf pfSense und hat bisher ohne Probleme gearbeitet... Es gab immer wieder Kleinigkeiten, die aber bei Serverneustart eliminiert werden konnten.
Da wir auf dem Server nichts umkonfiguriert haben, haben wir keine Ahnung. Die einzige Änderung ist, dass wir von dem Internetprovider eine eine neue fixe IP haben. Der VPN Config verwendet jetzt also diese IP und nicht die usprüngliche Domain.
Hat jemand eine Idee, wo alles die Probleme sein können?
Das Problem tritt nur im Windows Explorer auf. Wenn ich im Browser z. B. aufs NAS zugreifen möchte gibt es keine Probleme. Auch im WE klappte es zwei kleine Dateien zu übertragen. Die Verbindung ist also da ist aber extrem schlecht und es tritt eine Art Time-Out auf.
Im Standort 1 ist der pfSense hinter einem Fritzbox 6360, wo LAN2 auf Bridge gestellt ist und leitet Traffic auf die FW um.
Für ca. 10-15 Sekunde erreicht der Upload ca. 70-90KB / Sek (statt 300-400KB / Sec. --> Wir haben 5Mbit/s Upload) und dann geht die Verbindung zu NAS flöten.
Gr. I.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 258020
Url: https://administrator.de/forum/openvpn-verbindung-klappt-bricht-aber-bei-tatsaechlichem-kopieren-stets-ab-258020.html
Ausgedruckt am: 13.04.2025 um 05:04 Uhr
7 Kommentare
Neuester Kommentar
Hast du die MTU und MSS entsprechend angepasst auf dem WAN Port und LAN für den VPN Betrieb ?!
Danke, daran kann es liegen:
Im Log: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1442)
In Server-Confgi steht: udp-mtu 1500
Was sind die richtigen Werte?
Was kommt in Server-Config und was in Client-Config?
Ich würde gerne überall MTU 1500 benutzen?
MSS kenne ich noch weniger... Was soll hier eingetragen werden?
Ich denke eine clientseitige "mtu-test" wäre wohl die beste Möglichkeit, da die Kollegen mit Notebooks sehr of unterwegs sind.
Ich würde sowohl zum LAN und WAN Serverseitig "1500" eintragen.
MSS würde ich bei default-Wert (leer) lassen.
Mit "mtu-test" konnte ich schon eine 14MB Datei bei 250KB/s übertragen. Bei größeren Dateien kam wieder der Fehler. Ich denke es ist die richtige Richtung.
EDIT: wenn ich bei LAN und WAN 1500 eintrage klappt es überhaupt nicht mit der Verbindung.
Anhand von unterschiedlichen Ratschägen aus dem Internet habe ich mal "net.inet.ip.fastforwarding" in den pfSense Systemeinstellungen auf 1 gesetzt. Es hat auch nichts gebracht. ca. 70KB/s durchsatz. Nach 10MB --> Abbbruch.
Gr. I.
Im Log: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1442)
In Server-Confgi steht: udp-mtu 1500
Was sind die richtigen Werte?
Was kommt in Server-Config und was in Client-Config?
Ich würde gerne überall MTU 1500 benutzen?
MSS kenne ich noch weniger... Was soll hier eingetragen werden?
Ich denke eine clientseitige "mtu-test" wäre wohl die beste Möglichkeit, da die Kollegen mit Notebooks sehr of unterwegs sind.
Ich würde sowohl zum LAN und WAN Serverseitig "1500" eintragen.
MSS würde ich bei default-Wert (leer) lassen.
Mit "mtu-test" konnte ich schon eine 14MB Datei bei 250KB/s übertragen. Bei größeren Dateien kam wieder der Fehler. Ich denke es ist die richtige Richtung.
EDIT: wenn ich bei LAN und WAN 1500 eintrage klappt es überhaupt nicht mit der Verbindung.
Anhand von unterschiedlichen Ratschägen aus dem Internet habe ich mal "net.inet.ip.fastforwarding" in den pfSense Systemeinstellungen auf 1 gesetzt. Es hat auch nichts gebracht. ca. 70KB/s durchsatz. Nach 10MB --> Abbbruch.
Gr. I.
wenn ich bei LAN und WAN 1500 eintrage klappt es überhaupt nicht mit der Verbindung.
Na ja das ist ja klar...wie sollte das auch gehen ?? Die WAN MTU ist die max. MTU minis PPPoE Overhead minus VPN Overhead.Den solltest du mal auf 1418 setzenzum Testen. SSL VPNs haben nicht so einen großen Overhead wie IPsec so das vermutlich max. 1456 auch funktioniert.
Du kannst das auf als MSS Wert auf dem LAN Port setzen, denn sind die Framegrößen dort auf diesen Wert begrenzt. Bei SMB/CIFS Kopieren gibts eh nur kleine Dateien. Das Protokoll ist in der Beziehung bekanntlich ja sehr ineffizient.
Danke sehr,
Ich habe 1418 zu WAN MTU und 1456 zu LAN MSS eingetragen. In diesem Fall klappte aber die ganze Netzwerkverbindung nicht.
Wir haben diese Felder jahrelang völlig leergelassen und es hat funktioniert sehr stabil.
In meinem Fall neige ich dazu das Problem bei der Fritzbox zu sehen, die jetzt auf Auslieferungszustans zurückgesetzt wurde. Die KabelBW 6360-er führt Traffic zu pfSense weiter, der an LAN2 in Bridge-Modus angeschloßen wurde.
Es kann sein, dass diese Trafficweiterleitung nicht mehr zuverlässig funktioniert.
Ich habe mal sicherheitshalber auf LAN4 umgestellt.
Verbindung klappt aber mit der folgenden Fehlermeldung:
Tue Dec 23 00:00:53 2014 OpenVPN 2.3.5 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Oct 28 2014
Tue Dec 23 00:00:53 2014 library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.05
Tue Dec 23 00:00:54 2014 Control Channel Authentication: using 'pfsense-udp-1194-istvan-tls.key' as a OpenVPN static key file
Tue Dec 23 00:00:54 2014 UDPv4 link local (bound): [undef]
Tue Dec 23 00:00:54 2014 UDPv4 link remote: [AF_INET]xxx.192.xxx.101:1194
Tue Dec 23 00:01:06 2014 [openvpnserver] Peer Connection Initiated with [AF_INET]xxx.192.xxx.101:1194
Tue Dec 23 00:01:08 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Dec 23 00:01:08 2014 open_tun, tt->ipv6=0
Tue Dec 23 00:01:08 2014 TAP-WIN32 device [LAN-Verbindung 9] opened: \\.\Global\{11F6F082-E9CF-4348-8062-D88BE283DEFC}.tap
Tue Dec 23 00:01:08 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of 172.16.0.6/255.255.255.252 on interface {11F6F082-E9CF-4348-8062-D88BE283DEFC} [DHCP-serv: 172.16.0.5, lease-time: 31536000]
Tue Dec 23 00:01:13 2014 ROUTE: route addition failed using CreateIpForwardEntry: Zugriff verweigert [status=5 if_index=28]
Tue Dec 23 00:01:13 2014 env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Tue Dec 23 00:01:13 2014 ERROR: Windows route add command failed [adaptive]: returned error code 1
Tue Dec 23 00:01:13 2014 ROUTE: route addition failed using CreateIpForwardEntry: Zugriff verweigert [status=5 if_index=28]
Tue Dec 23 00:01:13 2014 env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Tue Dec 23 00:01:13 2014 ERROR: Windows route add command failed [adaptive]: returned error code 1
Tue Dec 23 00:01:13 2014 Initialization Sequence Completed
auf der Taskleiste "leuchtet" die Verbindung grün, interne IP kommt via DHCP "172.16.0.6/255.255.255.252"
Wir haben die damals so stabile Konfiguration seit Eweigkeiten nicht mehr geändert, daran kann es nicht liegen.
Ich bin auch als Admin angemeldet, Rechteprobleme dürften also keine Rolle spielen.
Die einzige Änderun, die ich sehe, dass beim OpenVPN-Server steht das Zertifikate "OpenVPN (CA: Firma)" (unter "Server Certificate") und in dem Client-Config "verify-x509-name "openvpnserver" name"
Kann es eventuell daran liegen?
Gr. I.
Ich habe 1418 zu WAN MTU und 1456 zu LAN MSS eingetragen. In diesem Fall klappte aber die ganze Netzwerkverbindung nicht.
Wir haben diese Felder jahrelang völlig leergelassen und es hat funktioniert sehr stabil.
In meinem Fall neige ich dazu das Problem bei der Fritzbox zu sehen, die jetzt auf Auslieferungszustans zurückgesetzt wurde. Die KabelBW 6360-er führt Traffic zu pfSense weiter, der an LAN2 in Bridge-Modus angeschloßen wurde.
Es kann sein, dass diese Trafficweiterleitung nicht mehr zuverlässig funktioniert.
Ich habe mal sicherheitshalber auf LAN4 umgestellt.
Verbindung klappt aber mit der folgenden Fehlermeldung:
Tue Dec 23 00:00:53 2014 OpenVPN 2.3.5 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Oct 28 2014
Tue Dec 23 00:00:53 2014 library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.05
Tue Dec 23 00:00:54 2014 Control Channel Authentication: using 'pfsense-udp-1194-istvan-tls.key' as a OpenVPN static key file
Tue Dec 23 00:00:54 2014 UDPv4 link local (bound): [undef]
Tue Dec 23 00:00:54 2014 UDPv4 link remote: [AF_INET]xxx.192.xxx.101:1194
Tue Dec 23 00:01:06 2014 [openvpnserver] Peer Connection Initiated with [AF_INET]xxx.192.xxx.101:1194
Tue Dec 23 00:01:08 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Dec 23 00:01:08 2014 open_tun, tt->ipv6=0
Tue Dec 23 00:01:08 2014 TAP-WIN32 device [LAN-Verbindung 9] opened: \\.\Global\{11F6F082-E9CF-4348-8062-D88BE283DEFC}.tap
Tue Dec 23 00:01:08 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of 172.16.0.6/255.255.255.252 on interface {11F6F082-E9CF-4348-8062-D88BE283DEFC} [DHCP-serv: 172.16.0.5, lease-time: 31536000]
Tue Dec 23 00:01:13 2014 ROUTE: route addition failed using CreateIpForwardEntry: Zugriff verweigert [status=5 if_index=28]
Tue Dec 23 00:01:13 2014 env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Tue Dec 23 00:01:13 2014 ERROR: Windows route add command failed [adaptive]: returned error code 1
Tue Dec 23 00:01:13 2014 ROUTE: route addition failed using CreateIpForwardEntry: Zugriff verweigert [status=5 if_index=28]
Tue Dec 23 00:01:13 2014 env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Tue Dec 23 00:01:13 2014 ERROR: Windows route add command failed [adaptive]: returned error code 1
Tue Dec 23 00:01:13 2014 Initialization Sequence Completed
auf der Taskleiste "leuchtet" die Verbindung grün, interne IP kommt via DHCP "172.16.0.6/255.255.255.252"
Wir haben die damals so stabile Konfiguration seit Eweigkeiten nicht mehr geändert, daran kann es nicht liegen.
Ich bin auch als Admin angemeldet, Rechteprobleme dürften also keine Rolle spielen.
Die einzige Änderun, die ich sehe, dass beim OpenVPN-Server steht das Zertifikate "OpenVPN (CA: Firma)" (unter "Server Certificate") und in dem Client-Config "verify-x509-name "openvpnserver" name"
Kann es eventuell daran liegen?
Gr. I.
Ich habe 1418 zu WAN MTU und 1456 zu LAN MSS eingetragen. In diesem Fall klappte aber die ganze Netzwerkverbindung nicht.
Das ist klar, denn die MSS darf nicht größer sein als die WAN MTU.der an LAN2 in Bridge-Modus angeschloßen wurde.
WAS meinst du genau mit dem Begriff "Bridge Modus" ?? Ist die FB als reines Kabel Modem konfiguriert, reicht also nur durch so das du die öffentliche Provider IP direkt an der pfSense hast so wie es eigentlich sein soll ??Es kann sein, dass diese Trafficweiterleitung nicht mehr zuverlässig funktioniert.
"Weiterleitung" klingt ja erstmal mehr nach Router als noch Modem....?? Bleibt also die Frage ob Modem oder kaskadierter Router vor der FW ?ROUTE: route addition failed using CreateIpForwardEntry: Zugriff verweiger
Das ist die klasssiche Fehlermeldung wenn der OVPN Client bei Winblows nicht mit Administrator Rechten rennt !!Die mit "push route..." propagierte Route kann er nicht an den Client weitergeben und im OS implementieren da die Rechte dazu fehlen...ein OVPN Klassiker bei Windows.
http://openvpn.net/index.php/open-source/faq/79-client/275-why-cant-i-r ...
http://www.heise.de/ct/hotline/OpenVPN-ohne-Admin-Rechte-320656.html
https://www.zendas.de/themen/server/openvpn/openvpn_windows.html
usw. usw.
Der Client bekommt dann nur die interne OVPN Tunnel IP aber NICHT die Route zum erreichen lokaler remoter netzresourcen ! Kannst du auch genau checken mit dem Kommando route print auf dem aktiven VPN Client. Dort sollte die Route ins remote lokale LAN via Tunnel IP dann fehlen weil die Route nicht gesetzt werden konnte aufgrund fehlender Rechte !
Das hat aber erstmal nix mit MTU und MSS zu tun sondern ist ne ganz andere Baustelle !
Ich bin auch als Admin angemeldet, Rechteprobleme dürften also keine Rolle spielen.
Die Fehlermeldung oben spricht aber klar eine ganz andere Sprache !!
Danke Aqui,
In diesem Fall schlagst du vor sowohl zu WAN MTU also auch zu LAN MMS 1418 einzutragen ...?
Mit "Bridge" meine ich, dass der / die pfSense hinter einen KabelBW Modem ist. Ich musste die FB etwas "aufbohren", damit die Möglichkeit besteht die einzelnen LAN Anschlüsse in "Bridge" MOdus zu ändern, damit die Firewall von draußen zu erreichen ist und es die IP von Provider bekommt ...
Die FB von KabelBW sind ziemlich "dumm". In Auslieferungszustand kann man den Router nicht abschalten.
Das mit den Rechten test ich nochmals. Ich habe mich extra als Admin angemeldet ... Habe den Dienst aber nicht als "Administrator" ausgeführt. Komisch.
Gr. I.
In diesem Fall schlagst du vor sowohl zu WAN MTU also auch zu LAN MMS 1418 einzutragen ...?
Mit "Bridge" meine ich, dass der / die pfSense hinter einen KabelBW Modem ist. Ich musste die FB etwas "aufbohren", damit die Möglichkeit besteht die einzelnen LAN Anschlüsse in "Bridge" MOdus zu ändern, damit die Firewall von draußen zu erreichen ist und es die IP von Provider bekommt ...
Die FB von KabelBW sind ziemlich "dumm". In Auslieferungszustand kann man den Router nicht abschalten.
Das mit den Rechten test ich nochmals. Ich habe mich extra als Admin angemeldet ... Habe den Dienst aber nicht als "Administrator" ausgeführt. Komisch.
Gr. I.
In diesem Fall schlagst du vor sowohl zu WAN MTU also auch zu LAN MMS 1418 einzutragen ...?
Zum Testen erstmal ja.... An den max. Wert kann man sich dann rantasten.Ich musste die FB etwas "aufbohren",.....Die FB von KabelBW sind ziemlich "dumm". In Auslieferungszustand kann man den Router nicht abschalten.
OK, verstanden, das ist dann alle FB spezifisch 
