Zugriff auf Synology NAS via VPN mit File-Explorer nicht möglich
Hallo zusammen
Ich habe auf meiner Pfsense (netgate sg 1100) und Routerkaskade FB den IKEV2 VPN gemäss Anleitung aon aqui (IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten) mit dem Win 10 VPN Client konfiguriert und kann mich mit dem VPN auf die pfsense verbinden. Funktioniert alles prima.
Ich habe folgendes Setup gewählt:
Als Koppelnetz habe ich den Bereich 192.168.180.0 /24 und als LAN den Bereich 192.168.179.0 /24 gewählt.
Aber der Zugriff auf mein Synology NAS welches sich hinter der pfsense befindet funktioniert nicht richtig. Ich erreiche das MAS mit dem Ping. Aber der Zugriff via dem File Explorer von Win 10 ist so so langsam. um die Dateistruktur anzuzeigen. Und Files kopieren funktioniert nicht. Ich habe schon alles versucht habe aber keine Ahnung voran das liegt. Wer kann mir helfen? Wenn ich mich mit meinem Laptop im LAN Netzwerk befinde, funktioniert der Zugriff auf die Daten im NAS sehr gut.
Noch etwas. Ich habe ein Test VPN aufgebaut und den VPN Client direkt mit dem WAN Anschluss der pfsense (netgate SG 1100) verbunden. Auch hier funktioniert die VPN Verbindung. Aber auch in diesem Fall besteht das gleiche Problem. An der davorliegenden FritzBox kann es nicht liegen.
Netzwerkeinstellung Synology NAS:
An der pfsense habe ich die folgenden Einstellungen vorgenommen:
Bitte versucht mir zu helfen. Ich bin dringend darauf angewiesen, dass der externe Zugriff auf mein NAS funktioniert.
Ich habe keine Ahnung, wo der Fehler liegt und bin am Anschlag. Bin ein ehrlicher Mensch. Ich werde der Person, welche mir das Problem löst, 100 CHF auf sein Konto überweisen.
Viele Grüsse René
Ich habe auf meiner Pfsense (netgate sg 1100) und Routerkaskade FB den IKEV2 VPN gemäss Anleitung aon aqui (IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten) mit dem Win 10 VPN Client konfiguriert und kann mich mit dem VPN auf die pfsense verbinden. Funktioniert alles prima.
Ich habe folgendes Setup gewählt:
Als Koppelnetz habe ich den Bereich 192.168.180.0 /24 und als LAN den Bereich 192.168.179.0 /24 gewählt.
Aber der Zugriff auf mein Synology NAS welches sich hinter der pfsense befindet funktioniert nicht richtig. Ich erreiche das MAS mit dem Ping. Aber der Zugriff via dem File Explorer von Win 10 ist so so langsam. um die Dateistruktur anzuzeigen. Und Files kopieren funktioniert nicht. Ich habe schon alles versucht habe aber keine Ahnung voran das liegt. Wer kann mir helfen? Wenn ich mich mit meinem Laptop im LAN Netzwerk befinde, funktioniert der Zugriff auf die Daten im NAS sehr gut.
Noch etwas. Ich habe ein Test VPN aufgebaut und den VPN Client direkt mit dem WAN Anschluss der pfsense (netgate SG 1100) verbunden. Auch hier funktioniert die VPN Verbindung. Aber auch in diesem Fall besteht das gleiche Problem. An der davorliegenden FritzBox kann es nicht liegen.
Netzwerkeinstellung Synology NAS:
An der pfsense habe ich die folgenden Einstellungen vorgenommen:
Bitte versucht mir zu helfen. Ich bin dringend darauf angewiesen, dass der externe Zugriff auf mein NAS funktioniert.
Ich habe keine Ahnung, wo der Fehler liegt und bin am Anschlag. Bin ein ehrlicher Mensch. Ich werde der Person, welche mir das Problem löst, 100 CHF auf sein Konto überweisen.
Viele Grüsse René
Please also mark the comments that contributed to the solution of the article
Content-ID: 3706989945
Url: https://administrator.de/contentid/3706989945
Printed on: October 15, 2024 at 15:10 o'clock
41 Comments
Latest comment
Moin Smith67,
ich sehe dein Problem schon. 😀
Deine MTU Einstellungen sind auf der pfsense etwas suboptimal eingestellt.
LAN-Seitig kannst du normalerweise 1500 benutzen, bei WAN kann ich dir das pauschal nicht sagen,
da es je nach Anschluss-Typ etwas variiert.
Es gibt aber duzende Anleitungen im Internet zu finden, wie man die WAN MTU korrekt ermitteln kann.
Hier z.B. eine von SonicWall
https://www.sonicwall.com/support/knowledge-base/how-can-i-determine-the ...
Der Post hier ist auch sehr interessant.
Frage zu MTU Werten auf allen Interfaces mit Multi WAN (Kabel und DSL Internet)
Und auch dieser Artikel ist sehr gut ...
https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulat ...
... und beschreibt auch genau dein Problem.
https://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encaps ...
Ferner solltest du auf dem Client mal den folgende Befehl ausführen.
Power Shell als Administrator
Wenn das geholfen hat, dann Spende die 100 CHF bitte an hilfsbedürftige Menschen, wie z.B. die Kriegsopfer in der Ukraine, danke.
Beste Grüsse aus BaWü
Alex
ich sehe dein Problem schon. 😀
Deine MTU Einstellungen sind auf der pfsense etwas suboptimal eingestellt.
LAN-Seitig kannst du normalerweise 1500 benutzen, bei WAN kann ich dir das pauschal nicht sagen,
da es je nach Anschluss-Typ etwas variiert.
Es gibt aber duzende Anleitungen im Internet zu finden, wie man die WAN MTU korrekt ermitteln kann.
Hier z.B. eine von SonicWall
https://www.sonicwall.com/support/knowledge-base/how-can-i-determine-the ...
Der Post hier ist auch sehr interessant.
Frage zu MTU Werten auf allen Interfaces mit Multi WAN (Kabel und DSL Internet)
Und auch dieser Artikel ist sehr gut ...
https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulat ...
... und beschreibt auch genau dein Problem.
https://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encaps ...
Ferner solltest du auf dem Client mal den folgende Befehl ausführen.
Power Shell als Administrator
New-ItemProperty -Type DWord -Path HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters -Name EnablePMTUBHDetect -value "1"
Bin ein ehrlicher Mensch. Ich werde der Person, welche mir das Problem löst, 100 CHF auf sein Konto überweisen.
Wenn das geholfen hat, dann Spende die 100 CHF bitte an hilfsbedürftige Menschen, wie z.B. die Kriegsopfer in der Ukraine, danke.
Beste Grüsse aus BaWü
Alex
Moin Smith67,
wenn wir schon dabei sind, dann kannst du auch gleich deinen SMB Client etwas optimieren. 😉
Power Shell als Administrator
und wenn das bei dir nicht hilft, dann kannst du mit dem folgenden Befehl, die oberen Einstellungen ganz einfach wieder auf Default setzen.
Beste Grüsse aus BaWü
Alex
wenn wir schon dabei sind, dann kannst du auch gleich deinen SMB Client etwas optimieren. 😉
Power Shell als Administrator
# SMB CLIENT OPTIMIZATION
#Get-SmbClientConfiguration
Set-SmbClientConfiguration -DirectoryCacheLifetime 0 -Confirm:$false
Set-SmbClientConfiguration -EnableBandwidthThrottling $false -Confirm:$false
Set-SmbClientConfiguration -FileInfoCacheLifetime 0 -Confirm:$false
Set-SmbClientConfiguration -FileNotFoundCacheLifetime 0 -Confirm:$false
Set-SmbClientConfiguration -WindowSizeThreshold 1 -Confirm:$false
Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 1 -Confirm:$false
Set-SmbClientConfiguration -MaxCmds 32768 -Confirm:$false
Set-SmbClientConfiguration -EnableSecuritySignature $true -Confirm:$false
Set-SmbClientConfiguration -RequireSecuritySignature $false -Confirm:$false
und wenn das bei dir nicht hilft, dann kannst du mit dem folgenden Befehl, die oberen Einstellungen ganz einfach wieder auf Default setzen.
Reset-SmbClientConfiguration -All -Confirm:$false
Beste Grüsse aus BaWü
Alex
Moin.
Ist das NAS auch gleichzeitig der interne DNS Server?
Du solltest nicht diesselbe IP für den primären und sekundären DNS Server verwenden.
Was das LAN Subnetz angeht, hast du dir das, nicht veränderbare, Gast-Netz der Fritzbox ausgesucht.
Wahrscheinlich ist beides nur Kosmetik, aber dennoch etwas, was du ändern solltest.
Sprichst du, verbunden mit dem VPN, das NAS mit dem DNS Namen oder dessen IP an?
Gruß
Marc
Ist das NAS auch gleichzeitig der interne DNS Server?
Du solltest nicht diesselbe IP für den primären und sekundären DNS Server verwenden.
Was das LAN Subnetz angeht, hast du dir das, nicht veränderbare, Gast-Netz der Fritzbox ausgesucht.
Wahrscheinlich ist beides nur Kosmetik, aber dennoch etwas, was du ändern solltest.
Sprichst du, verbunden mit dem VPN, das NAS mit dem DNS Namen oder dessen IP an?
Gruß
Marc
Nichtsdestotrotz hat dein NAS sich selbst als DNS Server definiert.
Das klingt nicht sinnvoll.
Hier sollte entweder die PFSense (diese übernimmt dann die Weiterleitung an externe Server) oder direkt ein externer DNS Server stehen.
Wie sprichst du denn nun das NAS an?
FQDN oder IP?
Welcher DNS Server wird in deiner IPSec VPN Verbindung gesetzt?
Gruß
Marc
Das klingt nicht sinnvoll.
Hier sollte entweder die PFSense (diese übernimmt dann die Weiterleitung an externe Server) oder direkt ein externer DNS Server stehen.
Wie sprichst du denn nun das NAS an?
FQDN oder IP?
Welcher DNS Server wird in deiner IPSec VPN Verbindung gesetzt?
Gruß
Marc
Es klingt so als wenn Pakete verworfen werden, weil die gewählte MTU zu groß ist.
Zumindest bei site-to-site muss die gewählte MTU kleiner als die Mindest-MTU der jeweiligen Partner sein.
Bedenke auch, dass auf Grund der Verschlüsselung der Overhead von der max. MTU abgezogen wird.
Setz die MTU testweise auf <1300 und guck was passiert (sowohl in der pfSense als auch in der remote Umgebung).
Zumindest bei site-to-site muss die gewählte MTU kleiner als die Mindest-MTU der jeweiligen Partner sein.
Bedenke auch, dass auf Grund der Verschlüsselung der Overhead von der max. MTU abgezogen wird.
Setz die MTU testweise auf <1300 und guck was passiert (sowohl in der pfSense als auch in der remote Umgebung).
Das lokale .179er Netz ist auch keine besonders intelligente Wahl, denn das nutzt die FB intern im Gastnetz. Auch wenn das in der FB aktuell nicht aktiv ist, ist es ebenso wie das Modem Bypass Netz latent vorhanden. Hier wäre die Wahl eine sinnvolleren IP Netzes deutlich zielführender gewesen. Siehe: VPNs einrichten mit PPTP
Bewirkt auch das das lokale LAN mit NAS mit einem VPN Client in einem klassischen FB Gastnetz Netz nicht erreichen werden kann (doppelte Netze).
Auch wenn die IP Adressierung sehr wahrscheinlich nicht das grundlegende Problem ist und diese wohl eher in der MTU liegt, ist die IP Adressierung etwas unglücklich.
Sinnvoll wäre sicherlich ein Ping um die max. MTU des VPN Tunnels zu ermitteln und die Anpassung der Tunnel MTU
https://blog.boll.ch/basic-stuff-mtu-groesse-mit-ping-testen/
https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on- ...
Bewirkt auch das das lokale LAN mit NAS mit einem VPN Client in einem klassischen FB Gastnetz Netz nicht erreichen werden kann (doppelte Netze).
Auch wenn die IP Adressierung sehr wahrscheinlich nicht das grundlegende Problem ist und diese wohl eher in der MTU liegt, ist die IP Adressierung etwas unglücklich.
Sinnvoll wäre sicherlich ein Ping um die max. MTU des VPN Tunnels zu ermitteln und die Anpassung der Tunnel MTU
https://blog.boll.ch/basic-stuff-mtu-groesse-mit-ping-testen/
https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on- ...
Moin René,
eigentlich nur an pfsense.
das sollte eigentlich bewirken , das Windows die korrekte MTU selbst ermitteln kann.
Kannst du von Client das NAS Pingen und auch umgekehrt, sprich, ist ICMP zwischen den beiden zugelassen?
Gruss Alex
Vielen Dank für Deine Beiträge. Ich weiss von meinem Internet Provider dass er eine MTU von 1492 hat. Muss ich nun diesen Wert im NAS und auf der pfsense einstellen.?
eigentlich nur an pfsense.
Der Befehl:
New-ItemProperty -Type DWord -Path HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters -Name EnablePMTUBHDetect -value "1"
hat keine Verbesserung gebracht. Was soll er bewirken?
New-ItemProperty -Type DWord -Path HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters -Name EnablePMTUBHDetect -value "1"
hat keine Verbesserung gebracht. Was soll er bewirken?
das sollte eigentlich bewirken , das Windows die korrekte MTU selbst ermitteln kann.
Kannst du von Client das NAS Pingen und auch umgekehrt, sprich, ist ICMP zwischen den beiden zugelassen?
Gruss Alex
eigentlich nur an pfsense.
Bzw. nur an einem WAN Port der mit PPPoE Encapsulation betrieben wird. Beim TO aber ja nicht der Fall da er die FW in einer reinen Ethernet Kaskade betreibt. Die vorgelagerte FB ist also für die Path MTU verantwortlichhttps://baturin.org/tools/encapcalc/
Die VPN Tunnel MTU ist durch die zusätzliche ESP Encapsulation noch kleiner. Primär ist die MTU also hier einzustellen.
Die MSS Size am LAN Port sollte dann entsprechend auch angepasst werden wenn das NAS nicht in der Lage ist die korrekte Path MTU zwischen sich und dem VPN Client zu ermitteln.
https://de.wikipedia.org/wiki/Path_MTU_Discovery
Mit einem QNAP NAS sind solcherlei Anpassungen nicht erforderlich in einem Standard Setup. Mit Ausnahme von Jumbo Framing. Ist Jumbo Framing auf dem NAS aktiviert scheitert ein Zugriff über den VPN Tunnel generell. Zumindestens ist das bei QNAP so. Das sollte der TO also ebenfalls prüfen.
Kannst du von Client das NAS Pingen und auch umgekehrt
Hatte der TO oben in der Beschreibung bejaht. ("Ich erreiche das MAS mit dem Ping.")Die miese Performance des Explorers spricht eher für eine Fragmentierung im Tunnel durch die falsche MTU.
Hier sollte ebenfalls 1500 stehen.
Bzw. LEER lassen was dann am LAN den Default 1500 nutzt.
Nur nebenbei: Google DNS zu verwenden macht kein normaler Mensch dem sein Datensicherheit wichtig ist. Das die von deinen Internet Gewohnheiten Profile erzeugen und diese weltweit an Dritte vermarkten weiss heute jeder Laie. Ein NoGo also was du als Profi eigentlich auch wissen solltest!
Als DNS gehört dort immer deine kaskadierte FritzBox eintragen, die ja automatisch den DNS des Providers verwendet (sie arbeitet als Proxy DNS). Ganz besonders wenn man noch Voice nebenbei macht.
Die korrekte DNS Einstellung der FW sollte man zudem ebenso beachten, ansonsten fragt die FW so oder so immer die Root Server.
Alternativ kannst du eine statische, feste IP Vergabe am WAN Port über die Mac Adress Reservierung der FB machen und den WAN Port der FW weiter als DHCP Client laufen lassen. Damit übernimmt sie dann die FB als DNS wie auch default Gateway automatisch.
Und...
Welche Firmware Version verwendest du auf der FW ?? Der Rechtschreibfehler im GUI
Ist in der aktuellen 2.6.0 längst gefixt!?!
Max. MTU Ping Check hast du bei aktivem VPN Tunnel gemacht? Was ist das Ergebnis?
Als DNS gehört dort immer deine kaskadierte FritzBox eintragen, die ja automatisch den DNS des Providers verwendet (sie arbeitet als Proxy DNS). Ganz besonders wenn man noch Voice nebenbei macht.
Die korrekte DNS Einstellung der FW sollte man zudem ebenso beachten, ansonsten fragt die FW so oder so immer die Root Server.
Alternativ kannst du eine statische, feste IP Vergabe am WAN Port über die Mac Adress Reservierung der FB machen und den WAN Port der FW weiter als DHCP Client laufen lassen. Damit übernimmt sie dann die FB als DNS wie auch default Gateway automatisch.
Und...
Welche Firmware Version verwendest du auf der FW ?? Der Rechtschreibfehler im GUI
Ist in der aktuellen 2.6.0 längst gefixt!?!
Im VPN habe ich kein DNS Server angegeben
Musst du auch nicht. Der VPN Client benutzt dann immer den DNS Server den er in seinem lokalen LAN bekommen hat.Max. MTU Ping Check hast du bei aktivem VPN Tunnel gemacht? Was ist das Ergebnis?
Na dann mal flott auf die aktuellste updaten.
Moin Aqui,
Ups, da hast du natürlich recht, habe mich von dem WAN in der Bezeichnung etwas verwirren lassen. 🙃
@René
dann bitte hier auch 1500 eintragen oder leer lassen.
Davon würde ich in diesem Stadium vorerst abraten, da das zu Nachteilen im LAN führt.
Path MTU Discovery sollte eigentlich auch bei Jumboframes greifen.
Gruss Alex
eigentlich nur an pfsense.
Bzw. nur an einem WAN Port der mit PPPoE Encapsulation betrieben wird. Beim TO aber ja nicht der Fall da er die FW in einer reinen Ethernet Kaskade betreibt. Die vorgelagerte FB ist also für die Path MTU verantwortlichUps, da hast du natürlich recht, habe mich von dem WAN in der Bezeichnung etwas verwirren lassen. 🙃
@René
dann bitte hier auch 1500 eintragen oder leer lassen.
Die MSS Size am LAN Port sollte dann entsprechend auch angepasst werden wenn das NAS nicht in der Lage ist die korrekte Path MTU zwischen sich und dem VPN Client zu ermitteln.
https://de.wikipedia.org/wiki/Path_MTU_Discovery
https://de.wikipedia.org/wiki/Path_MTU_Discovery
Davon würde ich in diesem Stadium vorerst abraten, da das zu Nachteilen im LAN führt.
Mit einem QNAP NAS sind solcherlei Anpassungen nicht erforderlich in einem Standard Setup. Mit Ausnahme von Jumbo Framing. Ist Jumbo Framing auf dem NAS aktiviert scheitert ein Zugriff über den VPN Tunnel generell.
Path MTU Discovery sollte eigentlich auch bei Jumboframes greifen.
Gruss Alex
Moin René,
das sollt eigentlich nicht geschehen das sind 92 Bytes zu wenig
Bei irgendetwas Richtung Internet ist die MTU noch auf 1400 gestellt. 😬
Du sagtest vorhin, dass du an dem NAS die MTU nicht kleiner als 1400 stellen kannst.
Das spricht irgendwie dafür, dass das NAS eine kleinere MTU, warum auch immer, nicht unterstützt.
Kannst du mal bitte den folgenden Befehl auf demselben Rechner in die CMD reinklopfen und die Ausgabe posten, danke.
Gruss Alex
das sollt eigentlich nicht geschehen das sind 92 Bytes zu wenig
Bei irgendetwas Richtung Internet ist die MTU noch auf 1400 gestellt. 😬
Du sagtest vorhin, dass du an dem NAS die MTU nicht kleiner als 1400 stellen kannst.
Das spricht irgendwie dafür, dass das NAS eine kleinere MTU, warum auch immer, nicht unterstützt.
Kannst du mal bitte den folgenden Befehl auf demselben Rechner in die CMD reinklopfen und die Ausgabe posten, danke.
netsh interface ipv4 show interfaces
Gruss Alex
Moin René,
die WAN MTU kann nicht 1400 sein, das ist viel zu wenig.
So sieht das z.B. bei mir Richtung WAN aus.
Und so um die Ecke sollte es bei dir eigentlich auch aussehen.
Gruss Alex
P.S. Und so sollte es im LAN aussehen, wenn alles in Ordnung ist.
Ich habe nun gemäss Deiner Anleitung die WAN MTU bestimmt. Sie beträgt genau 1400, also den Wert den ich eingetragen habe.
die WAN MTU kann nicht 1400 sein, das ist viel zu wenig.
So sieht das z.B. bei mir Richtung WAN aus.
Und so um die Ecke sollte es bei dir eigentlich auch aussehen.
Gruss Alex
P.S. Und so sollte es im LAN aussehen, wenn alles in Ordnung ist.
Moin Zusammen,
OK, jetzt stehe ich selber gewältigst auf dem Schlauch.
Ich habe bei meinem S2S IP-SEC Tunnel nun mal auf beiden Seiten die MTU Erkennung deaktiviert und wieder aktiviert ...
und seit dem bekomme ich 16 Bytes mehr pro Paket durch den VPN durch. 😖
Aber das ist nicht das was mich gerade so richtig kirre macht.
Ich habe aktuell noch einen SSL-VPN zu einem Kunden offen und über diesen kann ich einen seiner Server mit der vollen LAN MTU erreichen, also ob überhaupt kein VPN dazwischen wäre.
😵💫 ... wie genau funktioniert denn nun dieser Zauber?
Beste Grüsse aus BaWü
Alex
OK, jetzt stehe ich selber gewältigst auf dem Schlauch.
Ich habe bei meinem S2S IP-SEC Tunnel nun mal auf beiden Seiten die MTU Erkennung deaktiviert und wieder aktiviert ...
und seit dem bekomme ich 16 Bytes mehr pro Paket durch den VPN durch. 😖
Aber das ist nicht das was mich gerade so richtig kirre macht.
Ich habe aktuell noch einen SSL-VPN zu einem Kunden offen und über diesen kann ich einen seiner Server mit der vollen LAN MTU erreichen, also ob überhaupt kein VPN dazwischen wäre.
😵💫 ... wie genau funktioniert denn nun dieser Zauber?
Beste Grüsse aus BaWü
Alex
Moin Aqui,
scroll mal etwas nach oben, so bis ...
🙃
Sprich, ja diesen Artikel kenne ich und nein, dieser erklärt nicht das was ich momentan bei mir sehe.
Gruss Alex
scroll mal etwas nach oben, so bis ...
Und auch dieser Artikel ist sehr gut ...
https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulat ...
https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulat ...
🙃
Sprich, ja diesen Artikel kenne ich und nein, dieser erklärt nicht das was ich momentan bei mir sehe.
Gruss Alex
Moin Aqui,
Na das hier.
Und das durch einen SSL-VPN hindurch.
Na eben nicht.
Anfangsgrösse ohne VLAN 1518 Bytes - 14 Bytes vorne für dem Ethernet Header und 4 Bytes hinten für CRC =
1500 Bytes - 20 Bytes für den IP Header =
1480 Bytes - 8 Bytes für den ICMP Header = 1472 Bytes.
Das wäre im LAN so, aber ich gehe hier noch durch PPPoE und SSL-VPN und deren Header sollten doch auch noch
"dazwischenfunken".
Oder habe ich da jetzt etwas übersehen?
Gruss Alex
Was siehst du denn??
Na das hier.
Und das durch einen SSL-VPN hindurch.
ESP Encapsulation mit AES, plus TCP/UDP Header, plus VLAN Tag, plus PPPoE Header und man kommt auf deinen MTU Wert.
Na eben nicht.
Anfangsgrösse ohne VLAN 1518 Bytes - 14 Bytes vorne für dem Ethernet Header und 4 Bytes hinten für CRC =
1500 Bytes - 20 Bytes für den IP Header =
1480 Bytes - 8 Bytes für den ICMP Header = 1472 Bytes.
Das wäre im LAN so, aber ich gehe hier noch durch PPPoE und SSL-VPN und deren Header sollten doch auch noch
"dazwischenfunken".
Oder habe ich da jetzt etwas übersehen?
Gruss Alex
Der IP Header gehört doch schon zur Ethernet Payload von 1500.
Mit PPPoE Overhead ist die max. MTU 1492. Sprich der PPPoE Header mit 6 Octets und die PPP Protocol ID noch mit 2 Octets, so das die PPP MTU nicht größer als 1492 sein darf. Der klassische MTU Wert auf xDSL Routern. Die 10 Bytes sind dann dein SSL Encapsulation Overhead.
Mit PPPoE Overhead ist die max. MTU 1492. Sprich der PPPoE Header mit 6 Octets und die PPP Protocol ID noch mit 2 Octets, so das die PPP MTU nicht größer als 1492 sein darf. Der klassische MTU Wert auf xDSL Routern. Die 10 Bytes sind dann dein SSL Encapsulation Overhead.
Moin Aqui,
Nein das ist nicht richtig, der IP Header (20 Bytes) befindet sich innerhalb der Payload des Ethernetpakets.
Der Ethernetheader selber beinhaltet lediglich die Ziel-MAC (6 Bytes) dann die Quell-MAC (6 Bytes) und den Typ (2 Bytes) und hinten am Paket kommt noch FSC (4 Bytes) hinzu. Macht in Summe 18 Bytes.
1518 Bytes (Maximale-Ethernetpaketgrösse) - 18 Bytes = 1500 Bytes (Ethernet MTU).
Wenn du V-LAN im LAN verwendest, dann kommen beim Ethernet Header, zwischen der Quell-MAC und dem Typ noch weitere 4 Bytes für das V-LAN Tag (TPID/PRI(ToS)/CFI(CPI)/VID) hinzu. Jedoch kostet dieses V-LAN Tag keine MTU, da dabei die Maximale Ethernetpaketgrösse von 1518 Bytes auf 1522 Bytes angehoben wird.
Und innerhalb der MTU/Payload (1500 Bytes) des Ethernetheaders kommen dann normalerweise als nächstes der IP Header (20 Bytes), dann kommt der TCPv4 Header (20-60Bytes) oder der UDP Herder (8 Bytes) oder der ICMP Header (8 Bytes), oder andere Header wie ESP oder GRE.
Und so ergibt sich bei TCPv4 eine max. Payload von 1420-1460 Bytes und
bei UDP und ICMP sind es 1472 Bytes.
Das ist korrekt, PPPoE kostet unter dem Strich weitere 8 Bytes an Payload.
Bei TCPv4 mit PPPoE hast du dann eine max. Payload von 1412-1452 Bytes und
bei UDP&ICMP mit PPPoE beträgt die max. Payload 1464 Bytes.
Bei IPv6 ist der Header übrigens immer 40 Bytes goss.
Beste Grüsse aus BaWü
Alex
Der IP Header gehört doch schon zur Ethernet Payload von 1500.
Nein das ist nicht richtig, der IP Header (20 Bytes) befindet sich innerhalb der Payload des Ethernetpakets.
Der Ethernetheader selber beinhaltet lediglich die Ziel-MAC (6 Bytes) dann die Quell-MAC (6 Bytes) und den Typ (2 Bytes) und hinten am Paket kommt noch FSC (4 Bytes) hinzu. Macht in Summe 18 Bytes.
1518 Bytes (Maximale-Ethernetpaketgrösse) - 18 Bytes = 1500 Bytes (Ethernet MTU).
Wenn du V-LAN im LAN verwendest, dann kommen beim Ethernet Header, zwischen der Quell-MAC und dem Typ noch weitere 4 Bytes für das V-LAN Tag (TPID/PRI(ToS)/CFI(CPI)/VID) hinzu. Jedoch kostet dieses V-LAN Tag keine MTU, da dabei die Maximale Ethernetpaketgrösse von 1518 Bytes auf 1522 Bytes angehoben wird.
Und innerhalb der MTU/Payload (1500 Bytes) des Ethernetheaders kommen dann normalerweise als nächstes der IP Header (20 Bytes), dann kommt der TCPv4 Header (20-60Bytes) oder der UDP Herder (8 Bytes) oder der ICMP Header (8 Bytes), oder andere Header wie ESP oder GRE.
Und so ergibt sich bei TCPv4 eine max. Payload von 1420-1460 Bytes und
bei UDP und ICMP sind es 1472 Bytes.
Mit PPPoE Overhead ist die max. MTU 1492. Sprich der PPPoE Header mit 6 Octets und die PPP Protocol ID noch mit 2 Octets, so das die PPP MTU nicht größer als 1492 sein darf.
Das ist korrekt, PPPoE kostet unter dem Strich weitere 8 Bytes an Payload.
Bei TCPv4 mit PPPoE hast du dann eine max. Payload von 1412-1452 Bytes und
bei UDP&ICMP mit PPPoE beträgt die max. Payload 1464 Bytes.
Bei IPv6 ist der Header übrigens immer 40 Bytes goss.
Beste Grüsse aus BaWü
Alex
Wenn es das denn nun war bitte dann nicht vergessen deinen Thread auch als erledigt zu schliessen!
Es sind fast immer die üblichen Probleme...
Wenn ja solltest du die o.a. 3 Punkte genau klären.
- Das NAS hat ein fehlendes oder falsches Gateway. Es muss ein Gateway auf den VPN Router oder Firewall eingetragen haben
- Das NAS hat eine aktive lokale Firewall die Zugriffe aus Fremdnetzen blockiert aktiv
- Das NAS hat Jumbo Framing aktiviert also supportet Frames bzw. MTUs die über dem Default von 1500 liegen. Damit klappt dann kein VPN Zugang.
Wenn ja solltest du die o.a. 3 Punkte genau klären.
Dann ist auch IP routingtechnisch ja alles OK. Das kann dann einzig nur lokale Firewall oder die MTU/Jumbo Problematik sein! Bleibt ja sonst nix mehr...
Guter Test ist immer wenn man im NAS GUI Setup den SSH Zugriff auf die NAS Shell aktiviert bzw. freigibt.
Wenn man dann via VPN und PuTTY per SSH auf das NAS zugreifen kann muss es auch immer per Web GUI klappen.
Guter Test ist immer wenn man im NAS GUI Setup den SSH Zugriff auf die NAS Shell aktiviert bzw. freigibt.
Wenn man dann via VPN und PuTTY per SSH auf das NAS zugreifen kann muss es auch immer per Web GUI klappen.
Series: Zugriff auf Synology NAS mit Dateiexplorer sehr langsam beziehungsweise nicht möglich
Zugriff auf Synology NAS via VPN mit File-Explorer nicht möglich (german)41