Kopierabbrüche über VPN
Hallöchen,
wir haben ein Phänomen beim kopieren von Dateien, was ich mir aktuell nicht erklären kann und bitte um Mithilfe.
Es existiert eine Windows Freigabe auf einem Rechenzentrumsserver. Dort liegen beispielhaft 2 Dateien. Eine ist 12MB, die andere 38MB groß. Der Server ist über ein VPN zwischen zwei pfsensen mit einem LAN im Büro verbunden: Mode: Peer to Peer ( SSL/TLS )
Data Ciphers: AES-256-CBC
Digest: SHA256
D-H Params: Disabled, ECDH Only
Kopiert man die 12MB Datei, bleibt sie bei 55% hängen und bricht dann reproduzierbar ab. Kopiert man die 38MB Datei, ist alles ok. Von mehreren Rechnern das gleiche Bild. Beim Zugang vom HomeOffice ebenfalls über diese pfsense per VPN, allerdings ein separater VPN-Dienst, ist alles gut. Es gibt noch viele andere Dateien, die ok sind und eine handvoll Dateien, die nicht gehen. Auch Kopien gehen nicht.
Ich vermute schon die Umstellung von PreShared Key auf SSL/TLS dahinter, kann mir aber gar keinen Reim darauf machen. Vielleicht habt ihr eine Idee?
wir haben ein Phänomen beim kopieren von Dateien, was ich mir aktuell nicht erklären kann und bitte um Mithilfe.
Es existiert eine Windows Freigabe auf einem Rechenzentrumsserver. Dort liegen beispielhaft 2 Dateien. Eine ist 12MB, die andere 38MB groß. Der Server ist über ein VPN zwischen zwei pfsensen mit einem LAN im Büro verbunden: Mode: Peer to Peer ( SSL/TLS )
Data Ciphers: AES-256-CBC
Digest: SHA256
D-H Params: Disabled, ECDH Only
Kopiert man die 12MB Datei, bleibt sie bei 55% hängen und bricht dann reproduzierbar ab. Kopiert man die 38MB Datei, ist alles ok. Von mehreren Rechnern das gleiche Bild. Beim Zugang vom HomeOffice ebenfalls über diese pfsense per VPN, allerdings ein separater VPN-Dienst, ist alles gut. Es gibt noch viele andere Dateien, die ok sind und eine handvoll Dateien, die nicht gehen. Auch Kopien gehen nicht.
Ich vermute schon die Umstellung von PreShared Key auf SSL/TLS dahinter, kann mir aber gar keinen Reim darauf machen. Vielleicht habt ihr eine Idee?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 32440468380
Url: https://administrator.de/contentid/32440468380
Ausgedruckt am: 22.11.2024 um 15:11 Uhr
7 Kommentare
Neuester Kommentar
Moin.
Wie sind denn die Subnetze auf den beiden Seiten?
Hast du mal einen Paketmitschnitt auf beiden Seiten bei erfolglosem und erfolgreichem Kopieren erstellt und diesen dann mal im Wireshark gegengelesen?
Ist das ein IPSec Tunnel?
Mal einen Wireguard Tunnel zwischen den Sensen getestet?
Stehen die Sensen in einer Routerkaskade oder direkt hinter einem Modem?
Gibt es öffentliche, statische IPv4 Adressen an beiden Standorten?
Verrätst du uns das Protokoll auch?
Gruß
Marc
Wie sind denn die Subnetze auf den beiden Seiten?
Hast du mal einen Paketmitschnitt auf beiden Seiten bei erfolglosem und erfolgreichem Kopieren erstellt und diesen dann mal im Wireshark gegengelesen?
Ist das ein IPSec Tunnel?
Mal einen Wireguard Tunnel zwischen den Sensen getestet?
Stehen die Sensen in einer Routerkaskade oder direkt hinter einem Modem?
Gibt es öffentliche, statische IPv4 Adressen an beiden Standorten?
Zitat von 0sindbad0:
allerdings ein separater VPN-Dienst, ist alles gut.
allerdings ein separater VPN-Dienst, ist alles gut.
Verrätst du uns das Protokoll auch?
Gruß
Marc
Die Beschreibung ist in der Tat etwas wirr...
Man kann nur im freien Fall kristallkugeln welches VPN Protokoll auf welcher Hardware (AES/NI?!) der TO denn nun verwendet?
Bei "SSL/TLS" bleibt eigentlich nur das er sich vermutlich fatalerweise für das antike und mies performende OpenVPN statt IPsec mit IKEv2 auf den pfSense entschieden hat was aber nur geraten ist.
Bei solch großen Datentransfers sicherlich das völlig falsche VPN Protokoll und zur Anwendung völlig kontraproduktiv. Ein Bild sagt mehr als 1000 Worte.
Wenn dann auch noch obendrein TCP als Encapsulation gewählt wurde statt UDP (auch das müssen wir uns ja dazuraten... ) nimmt das Unglück dann seinen vorhersehbaren Lauf durch die dann mit Sicherheit auftretenden MSS und MTU Problematiken und dem o.a. typischen Fehlerbild.
Aber durch die recht oberflächlichen Informationen alles nur wilde Spekulation...
Mit einem sauberen IPsec, IKEv2 Site2Site VPN wäre das "Problem" gar nicht erst aufgetreten und der Thread vermutlich obsolet...
Man kann nur im freien Fall kristallkugeln welches VPN Protokoll auf welcher Hardware (AES/NI?!) der TO denn nun verwendet?
Bei "SSL/TLS" bleibt eigentlich nur das er sich vermutlich fatalerweise für das antike und mies performende OpenVPN statt IPsec mit IKEv2 auf den pfSense entschieden hat was aber nur geraten ist.
Bei solch großen Datentransfers sicherlich das völlig falsche VPN Protokoll und zur Anwendung völlig kontraproduktiv. Ein Bild sagt mehr als 1000 Worte.
Wenn dann auch noch obendrein TCP als Encapsulation gewählt wurde statt UDP (auch das müssen wir uns ja dazuraten... ) nimmt das Unglück dann seinen vorhersehbaren Lauf durch die dann mit Sicherheit auftretenden MSS und MTU Problematiken und dem o.a. typischen Fehlerbild.
Aber durch die recht oberflächlichen Informationen alles nur wilde Spekulation...
Mit einem sauberen IPsec, IKEv2 Site2Site VPN wäre das "Problem" gar nicht erst aufgetreten und der Thread vermutlich obsolet...
Ich schließe mich teilweise den anderen an.
Bitte mehr Informationen:
- Verwendete Hardware & pfSense Version?
- Was für eine Anbindung im RZ (Bandbreite, aber wenn ich von Unserem RZ ausgehe, sollte das kein Problem sein, wir sind mit 10Gbit/s angebunden)
- Verwendete VPN-Protokoll?
@aqui OpenVPN ist gar nicht mehr so langsam wenn man DCO Aktiviert
Bitte mehr Informationen:
- Verwendete Hardware & pfSense Version?
- Was für eine Anbindung im RZ (Bandbreite, aber wenn ich von Unserem RZ ausgehe, sollte das kein Problem sein, wir sind mit 10Gbit/s angebunden)
- Verwendete VPN-Protokoll?
@aqui OpenVPN ist gar nicht mehr so langsam wenn man DCO Aktiviert
Der Knackpunkt ist aber die fehlende Multiprozessor Fähigkeit und die lahme Verschlüsselung. Siehe auch hier.
Vermutlich aber eh egal, denn das fehlende Feedback des TOs zeigt ja ein Desinteresse an einer zielführenden Lösung.
Wie kann ich einen Beitrag als gelöst markieren?
Vermutlich aber eh egal, denn das fehlende Feedback des TOs zeigt ja ein Desinteresse an einer zielführenden Lösung.
Wie kann ich einen Beitrag als gelöst markieren?
@0sindbad0 Leider habe ich deinen Text nur teilweise verstanden:
Du schreibst, ihr habt eine Routerkaskade:
- Warum?
- Macht ihr Doppel/mehrfach NAT?
- Und wenn ihr doppel/mehrfach NAT macht, warum macht ihr das?
- Wenn du nur der der „Laienadmin“ bist, warum kümmert sich dann nicht der richtige admin darum oder ihr übergebt das eurem Dienstleiser, der ja vielleicht profi ist?
Damit wir dir vielleicht helfen können, bitte screenshots:
- OpenVPN Server Config (läuft die auf der pfSense)?
- pfSense version?
Bitte mal einen Detaillierten Grafischen Netzwerkplan, so können wir uns ein genaues Bild von dem Aufbau machen
PS: das ist nicht mehr aktuell "Data Ciphers: AES-256-CBC" Empfehlung ist "AES-256-GCM" & "CHACHA20-POLY1305"
Du schreibst, ihr habt eine Routerkaskade:
- Warum?
- Macht ihr Doppel/mehrfach NAT?
- Und wenn ihr doppel/mehrfach NAT macht, warum macht ihr das?
- Wenn du nur der der „Laienadmin“ bist, warum kümmert sich dann nicht der richtige admin darum oder ihr übergebt das eurem Dienstleiser, der ja vielleicht profi ist?
Damit wir dir vielleicht helfen können, bitte screenshots:
- OpenVPN Server Config (läuft die auf der pfSense)?
- pfSense version?
Bitte mal einen Detaillierten Grafischen Netzwerkplan, so können wir uns ein genaues Bild von dem Aufbau machen
PS: das ist nicht mehr aktuell "Data Ciphers: AES-256-CBC" Empfehlung ist "AES-256-GCM" & "CHACHA20-POLY1305"
Wenn es das denn nun war bitte dann auch nicht vergessen deinen Thread hier als erledigt zu schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?