11
Mikrotik VPN - Paketverlust
Hallo zusammen,
über Mikrotik Routerboards habe ich ein VPN aufgebaut. Leider läuft dieses nicht stabil. Die VPN Verbindungen haben einen Paketverlust. Probiert habe ich L2TP und PPTP jeweils mit und ohne IPsec Verschlüsselung.
Unter PPTP kommen Pakete wie z.B. Pings zwar meist an, an den Paketlaufzeiten erkennt man aber das es sich dabei um erneut gesendete Pakete handelt. UDP Pakete gehen über das VPN auch bei PPTP Verbindungen verloren. Siehe:
Wie kann ich vorgehen um eine Lösung dafür zu finden? Bin über jeden Hinweis dankbar.
Vielen Dank und ein schönes Wochenende!
über Mikrotik Routerboards habe ich ein VPN aufgebaut. Leider läuft dieses nicht stabil. Die VPN Verbindungen haben einen Paketverlust. Probiert habe ich L2TP und PPTP jeweils mit und ohne IPsec Verschlüsselung.
Unter PPTP kommen Pakete wie z.B. Pings zwar meist an, an den Paketlaufzeiten erkennt man aber das es sich dabei um erneut gesendete Pakete handelt. UDP Pakete gehen über das VPN auch bei PPTP Verbindungen verloren. Siehe:
Wie kann ich vorgehen um eine Lösung dafür zu finden? Bin über jeden Hinweis dankbar.
Vielen Dank und ein schönes Wochenende!
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: 227057
Url: https://administrator.de/contentid/227057
Ausgedruckt am: 05.11.2024 um 21:11 Uhr
11 Kommentare
Neuester Kommentar
In deinem Posting sind mehrere gravierende Verständnis Fehler:
Hier hast du also gravierende technische Verständnisprobleme was VPN Protokolle anbetrifft, sorry.
2 Fragen vorab bevor es ins Eingemachte geht:
- PPTP ist ein eigenes VPN Protokoll und hat rein gar nichts mit IPsec zu tun !
- PPTP basiert nicht auf TCP sondern auf GRE (IP Protokoll Nr. 47) ! Siehe hier !
- L2TP basiert nicht auf UDP sondern auf ESP das Teil vom drunterliegenden IPsec ist (IP Protokoll Nr. 50) !
Hier hast du also gravierende technische Verständnisprobleme was VPN Protokolle anbetrifft, sorry.
2 Fragen vorab bevor es ins Eingemachte geht:
- Aktuelle Firmware hast du auf dem Mikrotik installiert ?
- Das IPsec/L2TP Tutorial hier_im_Forum hast du gelesen ?
- Das PPTP Tutorial hier_im_Forum hast du gelesen ?
Hallo,
Das RB1200 hat nachweislich bei ca. 10 Leuten die ich kenne und auch
einigen Leuten im MikroTik Forum, echte Latenzprobleme und ist für VPNs
eben nicht so zu gebrauchen wie das RB110AHx2 was eine Hardwareunterstützung
genau dafür mitbringt! Also wer den Schwerpunkt auf VPNs legt und dort dann auch
richtig Durchsatz braucht, sollte auf die RB 1100AHx2 setzen und nicht auf die
RB1200 Serie, das ist ein alt bekanntes Problem doch einige Leute kaufen halt erst
und testen bzw. informieren sich dann erst.
Mit zwei RB1100AHx2 sollte das ganze richtig schnell laufen und die Latenzen sollten
dann auch der Vergangenheit angehören, denn es kommt auch immer ein wenig darauf an
wie viele Daten man durch sein VPN "pumpt" und das wird bei @aqui seinem Anleitungen wohl
auch weniger sein als es bei dem o.g. Beispiel.
Gruß
Dobby
Das RB1200 hat nachweislich bei ca. 10 Leuten die ich kenne und auch
einigen Leuten im MikroTik Forum, echte Latenzprobleme und ist für VPNs
eben nicht so zu gebrauchen wie das RB110AHx2 was eine Hardwareunterstützung
genau dafür mitbringt! Also wer den Schwerpunkt auf VPNs legt und dort dann auch
richtig Durchsatz braucht, sollte auf die RB 1100AHx2 setzen und nicht auf die
RB1200 Serie, das ist ein alt bekanntes Problem doch einige Leute kaufen halt erst
und testen bzw. informieren sich dann erst.
Mit zwei RB1100AHx2 sollte das ganze richtig schnell laufen und die Latenzen sollten
dann auch der Vergangenheit angehören, denn es kommt auch immer ein wenig darauf an
wie viele Daten man durch sein VPN "pumpt" und das wird bei @aqui seinem Anleitungen wohl
auch weniger sein als es bei dem o.g. Beispiel.
Gruß
Dobby
Hallo,
einfach mal ins Wiki schauen da steht folgendes:
PPTP
PPTP traffic uses TCP port 1723 and IP protocol GRE (Generic Routing Encapsulation, IP protocol ID 47), as assigned by the Internet Assigned Numbers Authority (IANA). PPTP can be used with most firewalls and routers by enabling traffic destined for TCP port 1723 and protocol 47 traffic to be routed through the firewall or router.
L2TP
L2TP traffic uses UDP protocol for both control and data packets. UDP port 1701 is used only for link establishment, further traffic is using any available UDP port (which may or may not be 1701). This means that L2TP can be used with most firewalls and routers (even with NAT) by enabling UDP traffic to be routed through the firewall or router.
Handelt es sich hierbei um IPSec/L2TP oder nur L2TP?
Hast Du auch Paketverluste ohne VPN? Wenn nicht, macht die Einwahl der Router oder ist es eine Standleitung? Ein solches Problem wird auch häufig im Mikrotik Forum diskutiert und dort geht es bei den meisten Threads in Richtung MTU. Da solltest Du dir mal den Taschenrechner nehmen und nachrechen ob das passt was in den Routern steht.
Was sagt denn die CPU während deines Tests?
Beim 750er tunnel ich bei 100% CPU Last ca. 15 Mbit/s über L2TP und gute 8-10 Mbit/s über OpenVPN.
Gruß
Heiko
einfach mal ins Wiki schauen da steht folgendes:
PPTP
PPTP traffic uses TCP port 1723 and IP protocol GRE (Generic Routing Encapsulation, IP protocol ID 47), as assigned by the Internet Assigned Numbers Authority (IANA). PPTP can be used with most firewalls and routers by enabling traffic destined for TCP port 1723 and protocol 47 traffic to be routed through the firewall or router.
L2TP
L2TP traffic uses UDP protocol for both control and data packets. UDP port 1701 is used only for link establishment, further traffic is using any available UDP port (which may or may not be 1701). This means that L2TP can be used with most firewalls and routers (even with NAT) by enabling UDP traffic to be routed through the firewall or router.
Handelt es sich hierbei um IPSec/L2TP oder nur L2TP?
Hast Du auch Paketverluste ohne VPN? Wenn nicht, macht die Einwahl der Router oder ist es eine Standleitung? Ein solches Problem wird auch häufig im Mikrotik Forum diskutiert und dort geht es bei den meisten Threads in Richtung MTU. Da solltest Du dir mal den Taschenrechner nehmen und nachrechen ob das passt was in den Routern steht.
Was sagt denn die CPU während deines Tests?
Beim 750er tunnel ich bei 100% CPU Last ca. 15 Mbit/s über L2TP und gute 8-10 Mbit/s über OpenVPN.
Gruß
Heiko
Dennoch habe ich den im PPTP Tunnel laufenden Traffic mit IPsec verschlüsselt. PPTP ist von meiner Seite her nicht das priorisierte Protokoll, sondern ein Versuch ob es damit besser geht (dadurch das bei PPTP verloren gegangene Pakete erkannt und neu angefordert werden).
* PPTP basiert nicht auf TCP sondern auf GRE (IP Protokoll Nr. 47) ! Siehe
hier !
500. Produktivdaten werden aber immer in den o.a. Tunnelprotokollen transportiert.
Hier hast du also gravierende technische Verständnisprobleme was VPN Protokolle anbetrifft, sorry.
hier !
- L2TP basiert nicht auf UDP sondern auf ESP das Teil vom drunterliegenden IPsec ist (IP Protokoll Nr. 50) !
500. Produktivdaten werden aber immer in den o.a. Tunnelprotokollen transportiert.
Hier hast du also gravierende technische Verständnisprobleme was VPN Protokolle anbetrifft, sorry.
OK, ich habe mich vielleicht etwas unglücklich ausgedrückt und nicht alles perfekt dargestellt. Sorry, mein CCNA ist leider schon viele Jahre alt und nicht mehr ganz frisch. Dennoch sollten wir schauen wie die Problemlösung angegangen werden kann.
* Aktuelle Firmware hast du auf dem Mikrotik installiert ?
Ja, wie auf den eingebundenen Grafiken ersichtlich ist auf beiden Routern die aktuelle Version 6.7 drauf.
* Das IPsec/L2TP Tutorial hier_im_Forum hast du gelesen ?
Bislang hatte ich mich an das Mikrotik Tutorial (http://wiki.mikrotik.com/wiki/Manual:Interface/L2TP) gehalten. Hole ich aber nach...
Ein Ping- oder Paketverlust ist bei den im Tutorial beschriebenen Konfigurationen beim RB750 nachweislich nicht festzustellen.
Einen grundsätzlichen Paketverlust habe ich auch nicht. TCP Pakete gehen ohne Problem durch. Wie aus der Tabelle ersichtlich liegt das Problem hauptsächlich bei großen fragmentierten Paketen und bei der Übertragung von vielen UDP Paketen.
Zitat von @108012:
Das RB1200 hat nachweislich bei ca. 10 Leuten die ich kenne und auch
einigen Leuten im MikroTik Forum, echte Latenzprobleme und ist für VPNs
eben nicht so zu gebrauchen wie das RB110AHx2 was eine Hardwareunterstützung
genau dafür mitbringt! Also wer den Schwerpunkt auf VPNs legt und dort dann auch
richtig Durchsatz braucht, sollte auf die RB 1100AHx2 setzen und nicht auf die
RB1200 Serie, das ist ein alt bekanntes Problem doch einige Leute kaufen halt erst
und testen bzw. informieren sich dann erst.
Das RB1200 hat nachweislich bei ca. 10 Leuten die ich kenne und auch
einigen Leuten im MikroTik Forum, echte Latenzprobleme und ist für VPNs
eben nicht so zu gebrauchen wie das RB110AHx2 was eine Hardwareunterstützung
genau dafür mitbringt! Also wer den Schwerpunkt auf VPNs legt und dort dann auch
richtig Durchsatz braucht, sollte auf die RB 1100AHx2 setzen und nicht auf die
RB1200 Serie, das ist ein alt bekanntes Problem doch einige Leute kaufen halt erst
und testen bzw. informieren sich dann erst.
Das Problem taucht nicht nur beim RB1200 auf. Wir haben die Probleme auch bei anderen Routerboards (z.B. den 450er). Zudem liegt die CPU Last bei der Übertragung im einstelligen Bereich. Es kommt also nicht auf die Hardware an (wäre ja auch mega peinlich, wenn ein RB1200 bei der Übertragung von wenigen Seiten Text hardwarebedingt Pakete verschlucken würde).
Habe beides probiert (siehe Tabelle im ersten Beitrag).
Hast Du auch Paketverluste ohne VPN? Wenn nicht, macht die Einwahl der Router oder ist es eine Standleitung? Ein solches Problem
wird auch häufig im Mikrotik Forum diskutiert und dort geht es bei den meisten Threads in Richtung MTU.
wird auch häufig im Mikrotik Forum diskutiert und dort geht es bei den meisten Threads in Richtung MTU.
Ohne VPN ist es in Ordnung. Die MTU Werte überprüfe ich nochmals.
Was sagt denn die CPU während deines Tests?
Die CPU Auslastung bleibt im einstelligen Bereich (also unter 10%).
Beim 750er tunnel ich bei 100% CPU Last ca. 15 Mbit/s über L2TP und gute 8-10 Mbit/s über OpenVPN.
Getestet habe ich es gegen die Zentrale (RB/1100AHx2) mit RB/1200 und RB/450G (beides sehr potente Modelle). Die Paketverluste kommen auch schon nach recht wenig Daten (in dem oben abgebildeten Beispiel sind nicht mal 2 MB ordentlich übertragen worden.
Zitat von @exchange:
Hast Du auch Paketverluste ohne VPN? Wenn nicht, macht die Einwahl der Router oder ist es eine Standleitung? Ein solches Problem
wird auch häufig im Mikrotik Forum diskutiert und dort geht es bei den meisten Threads in Richtung MTU. Da solltest Du dir
mal den Taschenrechner nehmen und nachrechen ob das passt was in den Routern steht.
Hast Du auch Paketverluste ohne VPN? Wenn nicht, macht die Einwahl der Router oder ist es eine Standleitung? Ein solches Problem
wird auch häufig im Mikrotik Forum diskutiert und dort geht es bei den meisten Threads in Richtung MTU. Da solltest Du dir
mal den Taschenrechner nehmen und nachrechen ob das passt was in den Routern steht.
Hallo Heiko,
das mit der MTU war schon richtig gut. In der GS 0 war die MTU für das Internet richtig eingestellt (1456 Byte, da getunnelter Multilink PPPoE Zugang). Die L2TP Verbindung stand allerdings auf 1460. Diese habe ich jetzt auf 1424 Bytes (1456 - 32) eingestellt. Seit dem ist der Paketverlust auf der VPN Strecke auf 2 - 3% (wohlgemerkt bei Pings mit 16.000 Byte Paketen) gesunken.
Bei der nächsten Geschäftsstelle (10) hat das leider nichts gebracht. Hier liegt ein Business ADSL Zugang der Telekom an, welcher eine MTU von 1492 Bytes hat. Der L2TP Zugang ist folgerichtig auf 1460 Bytes (1492 - 32) eingestellt. Diese Zahlen habe ich mit unfragmentieren Pings in jeweils dieser Paketgröße validieren können.
Leider ist die Verbindung zwischen GS 10 und Zentrale immer noch sehr schlecht. Die 16k Pings haben auf der VPN Strecke einen Paketverlust von 77 - 80% und ins Internet (zu www.google.de) immer noch 8%. Die CPU Last ist bei allen Geräten unter 12% geblieben.
Ich habe das Problem mal skizziert:
http://www.jelinski.de/temp/140120_paketverlust.png
Wieso hat es bei GS 0 geklappt und bei GS 10 nicht?
PS. Bei normalen Pings (50 Byte) ist alles in Ordnung.
Durch ein wenig rumprobieren habe ich herausgefunden das der Paketverlust der großen 16k Pakete sich enorm reduziert, wenn ich die MTU der L2TP Verbindung von 1460 auf einen kleineren Wert einstelle (im Moment 1424 Byte - obwohl 1460er ohne Fragmentierung möglich wären). Dadurch ist der Paketverlust von vorher 77 - 80% auf 2 - 6% gesunken.
Wie kann das zusammen hängen? Ich bin immer davon ausgegangen das die maximale Paketgröße ein fester Wert ist, der sich aus den Leitungseigenschaften und den darüber zu transportierenden Protokollen zusammen setzt.
Ich teste die Leitung nun mal ein wenig mit den reduzierten Werten und sehe dann weiter.
Wie kann das zusammen hängen? Ich bin immer davon ausgegangen das die maximale Paketgröße ein fester Wert ist, der sich aus den Leitungseigenschaften und den darüber zu transportierenden Protokollen zusammen setzt.
Ich teste die Leitung nun mal ein wenig mit den reduzierten Werten und sehe dann weiter.
Bei deinen 1460er Wert kommt es darauf an ob der Header mitgerechnet wird oder nicht.
Das MTU Problem resultiert aus der doppelten Encapsulation bei VPN bzw. der dann noch folgenden Encapsulation in DSL PPPoE.
Hier findest du einen Erklärung:
http://www.cisco.com/en/US/tech/tk175/tk15/technologies_tech_note09186a ...
Hier noch Tps sich an den realen Wert anzupirschen:
http://www.gschwarz.de/mtu-wert-ermitteln
http://www.tippscout.de/windows-7-mtu-optimieren-download-abgebrochen_t ...
Das MTU Problem resultiert aus der doppelten Encapsulation bei VPN bzw. der dann noch folgenden Encapsulation in DSL PPPoE.
Hier findest du einen Erklärung:
http://www.cisco.com/en/US/tech/tk175/tk15/technologies_tech_note09186a ...
Hier noch Tps sich an den realen Wert anzupirschen:
http://www.gschwarz.de/mtu-wert-ermitteln
http://www.tippscout.de/windows-7-mtu-optimieren-download-abgebrochen_t ...
So, nun habe ich nochmal sauber alles nachgerechnet. Bislang bin ich davon ausgegangen das ich bei L2TP ohne IPsec 32 Byte von der MTU des Internetzugangs abziehen müsste. Laut Cisco sind es aber 40 Byte, da der IP Header da nicht mit reingerechnet sondern noch aufgeschlagen wird.
Per MTU Path habe ich die maximal mögliche MTU der Internetzugänge der einzelnen Standorte ausgemessen. Dabei ist folgendes herausgekommen (was schon bekannt war):
ADSL Telekom Business Anschlüsse: MTU = 1492
ADSL ML-PPP Anschlüsse: MTU = 1456
SDSL 10 MBit Anschlüsse (CompanyConnect): MTU = 1500
SDSL 10 MBit Anschlüsse (CompanyConnect): MTU = 1500
Kabel 30 MBit Anschlüsse: MTU = 1500
Davon müssten für den L2TP dann 40 Byte und für ESP (IPsec) noch zusätzliche 73 Byte heruntergerechnet werden. Ergibt dann:
ADSL Telekom Business Anschlüsse: 1492 - 40 - 73 = MTU 1379
ADSL ML-PPP Anschlüsse: 1456 - 40 - 73 = MTU 1343
SDSL 10 MBit Anschlüsse (CompanyConnect): 1500 - 40 - 73 = MTU 1387
SDSL 10 MBit Anschlüsse (CompanyConnect): 1500 - 40 - 73 = MTU 1387
Kabel 30 MBit Anschlüsse: 1500 - 40 - 73 = MTU 1387
Dieses habe ich nun an allen Anschlüssen so eingestellt, IPsec testhalber deaktiviert und wieder 16k Pings durchgeführt. Dabei ist folgendes Ergebniss entstanden:
An 6 von 7 ADSL Anschlüssen habe ich einen Paketverlust von 0% (perfekt)
An 1 von 7 ADSL Anschlüssen habe ich einen Paketverlust von 3% (wieso?)
An den SDSL (Telekom CompanyConnect) Anschlüssen habe ich einen Paketverlust von 0% (perfekt)
Und an dem einen ML-PPP Anschluss habe ich einen Paketverlust von 1%
Damit ist das alles schon mal fast gut. Doch wieso habe ich immer noch Paketverlust auf 2 Anschlüssen?
Macht es eventuell Sinn per MRRU die Paketgröße der fragmentierenden Pakete zu begrenzen? Falls ja, welche Größe macht da Sinn?
Per MTU Path habe ich die maximal mögliche MTU der Internetzugänge der einzelnen Standorte ausgemessen. Dabei ist folgendes herausgekommen (was schon bekannt war):
ADSL Telekom Business Anschlüsse: MTU = 1492
ADSL ML-PPP Anschlüsse: MTU = 1456
SDSL 10 MBit Anschlüsse (CompanyConnect): MTU = 1500
SDSL 10 MBit Anschlüsse (CompanyConnect): MTU = 1500
Kabel 30 MBit Anschlüsse: MTU = 1500
Davon müssten für den L2TP dann 40 Byte und für ESP (IPsec) noch zusätzliche 73 Byte heruntergerechnet werden. Ergibt dann:
ADSL Telekom Business Anschlüsse: 1492 - 40 - 73 = MTU 1379
ADSL ML-PPP Anschlüsse: 1456 - 40 - 73 = MTU 1343
SDSL 10 MBit Anschlüsse (CompanyConnect): 1500 - 40 - 73 = MTU 1387
SDSL 10 MBit Anschlüsse (CompanyConnect): 1500 - 40 - 73 = MTU 1387
Kabel 30 MBit Anschlüsse: 1500 - 40 - 73 = MTU 1387
Dieses habe ich nun an allen Anschlüssen so eingestellt, IPsec testhalber deaktiviert und wieder 16k Pings durchgeführt. Dabei ist folgendes Ergebniss entstanden:
An 6 von 7 ADSL Anschlüssen habe ich einen Paketverlust von 0% (perfekt)
An 1 von 7 ADSL Anschlüssen habe ich einen Paketverlust von 3% (wieso?)
An den SDSL (Telekom CompanyConnect) Anschlüssen habe ich einen Paketverlust von 0% (perfekt)
Und an dem einen ML-PPP Anschluss habe ich einen Paketverlust von 1%
Damit ist das alles schon mal fast gut. Doch wieso habe ich immer noch Paketverlust auf 2 Anschlüssen?
Macht es eventuell Sinn per MRRU die Paketgröße der fragmentierenden Pakete zu begrenzen? Falls ja, welche Größe macht da Sinn?
Das macht durchaus Sinn ! Wenn du bei deinem Router das auf den lokalen LAN Interfaces entsprechend setzen kannst.
Bei einem Cisco Router ist das z.B. das Kommando ip tcp adjust-mss 1452
Damit sollten die Paket Losses dann vollständig verschwinden.
Bei einem Cisco Router ist das z.B. das Kommando ip tcp adjust-mss 1452
Damit sollten die Paket Losses dann vollständig verschwinden.
Zitat von @aqui:
Das macht durchaus Sinn ! Wenn du bei deinem Router das auf den lokalen LAN Interfaces entsprechend setzen kannst.
Bei einem Cisco Router ist das z.B. das Kommando ip tcp adjust-mss 1452
Damit sollten die Paket Losses dann vollständig verschwinden.
Das macht durchaus Sinn ! Wenn du bei deinem Router das auf den lokalen LAN Interfaces entsprechend setzen kannst.
Bei einem Cisco Router ist das z.B. das Kommando ip tcp adjust-mss 1452
Damit sollten die Paket Losses dann vollständig verschwinden.
Auch bei den genutzten Mikrotik Routern kann man die MRRU begrenzen. Das Problem was ich dabei sehe: Wenn ich per MRRU festlege das keine Pakete größer x Byte mehr empfangen werden können, was passiert dann mit größeren Paketen? Im Moment werden diese ja einfach fragmentiert. Werden die dann einfach weggeworfen, abgewiesen oder wie muss ich mir das vorstellen?
Die aktuellen Einstellungen lauten (am Beispiel des Routerstandortes, welcher mit ML-PPP ins Netz kommt):
name="L2TP_entfernt" max-mtu=1343 max-mru=1343 mrru=disabled connect-to=IP_entfernt user="entfernt" password="entfernt" profile=default-encryption keepalive-timeout=60 add-default-route=no dial-on-demand=no allow=mschap2
