AW: VPN Verbindung stabil, aber sehr langsam

[#1]

Sehr geehrte Damen und Herren,

wir sind ein Unternehmen aus Polen mit einer Filiale in Berlin. In dieser Filiale verbinden sich die User über einen VPN-Client (Forticlient) mit den Strukturen in Polen und arbeiten mittels einer Software an Datenbeständen und dergleichen. 

Die Verbindungsherstellung funktioniert und die VPN-Verbindung steht.

Nun ist es so, dass User zunächst berichteten, dass sie beim Aufrufen des Warenbestandes etwa eine Minute warten müssten, bis dieser erscheint. Nach Rücksprache mit den Serveradministratoren in Polen werden die Daten dort sehr langsam abgeholt, obwohl der Backbone-Server dort keine Kapazitätsgrenzen erreicht.

Die Verbindung ist stabil, aber der Download hier in Deutschland ist unglaublich langsam, obwohl die VDSL2 (50Mbit)-Verbindung super aussieht und auch keine Belastungen stattfinden, die die Bandbreite wesentlich schmälern dürften.

Testweise habe ich ein Firmenlaptop mit nach Hause genommen und die, aktuell in der Firma eingesetzte Installation einfach mal am Heimischen Billig-DSL sowie am WLAN eines Internetcafés sowie in einem benachbarten Hotel-WLAN ausprobiert. Dort wird das Aufrufen des Artikelbestandes in einem Sechzigstel der Zeit (Der Zugriff dauert statt einer Minute genau eine Sekunde) erledigt. Da der Zugriff auf die Artikel durch die NAT auf der Digitalisierungsbox Premium oder durch Firewall-Software blockiert wird, sondern nur erheblich verlangsamt wird, tippe ich auf ein ähnliches Problem wie das nachfolgend verlinkte und bitte dies auch bei uns abzustellen, damit wir wieder in der Lage sind unseren Kundenauftrag zeitgerecht wahrzunehmen.

Hier das verlinkte Problem:

https://telekomhilft.telekom.de/t5/Telefonie-Daten/VPN-Verbindung-funktioniert-wird-jedoch-seitens-d...

Vielen Dank

Perfumi 

[#2]

Was hat der verlinkte Thread damit zutun?
Ein paar reine Fakten wären auch nicht schlecht.

Tarif?
Datenrate außerhalb vom VPN?
Datenrate im VPN?

[#3]

Wenn das Problem nur mit VPN Auftritt, würd eich mal,vermuten, dass es mit einer fehlerhaften Konfiguration (MTU möglicherweise) zu tun hat.  

Einfach mal testweise den reinen Durchsatz ohne VPN messen.

[#4]

Ohne VPN-Verbindung nach Polen können wir die Software nicht nutzen, da sie auf die Datenbestände in Polen zurückgreift und sich ohne VPN-Verbindung nicht mit den Servern in Polen verbinden kann. Alles, was nicht VPN-basiert abläuft ist stabil und sehr schnell. Alles was VPN-basiert abläuft ist stabil, aber langsam. Daher tippte ich auch auf den Thread, den ich eingangs verlinkte. War aber nur eine Vermutung.

Wir haben einen Telekom Geschäftskunden-Tarif:

DeutschlandLAN-IP/Voice Data L Premium mit VDSL2 50 Mbits Download und 10 Mbit Upload

Beide Datenraten stimmen ohne VPN, mit VPN wirds aber wirklich spärlich..

[#5]

BTW: womit würdet ihr den Datendurchsatz bei diesem speziellen Problem am ehesten messen?

[#6]

Am einfachsten ließe sich die Bandbreite nun speziell testen, wenn in Polen von dem Admin ein FTP Server am gleichen Standort freigegeben wird, auf dem ihr über das normale Internet zugreifen könnt.

Dann könnt Ihr einfach schauen, ob die Route ohne VPN Performant im UP/Downstream ist.

[#7]

Ah, das lässt sich leicht beantworten. Das läuft höchst performant. Es gibt am Firmen-FTP immer einen Ordner mit Media-Dateien für die lokalen Werbemaßnahmen (Flyer/Poster etc.). Das hab ich grad getestet und die Daten fließen mit durchschnittlich 27 Mbit also wirklich super!

[#8]

---

@Perfumi schrieb:

Ah, das lässt sich leicht beantworten. Das läuft höchst performant. Es gibt am Firmen-FTP immer einen Ordner mit Media-Dateien für die lokalen Werbemaßnahmen (Flyer/Poster etc.). Das hab ich grad getestet und die Daten fließen mit durchschnittlich 27 Mbit also wirklich super!

---

Dann liegt es nur am Tunnel - was meinen Verdacht mit einer falschkonfiguration nur bestärkt 

[#9]

Um den Hintergrund zu erklären .. ein Paket im PPPoE Frame darf nur eine bestimmte maximale Größe (1492 Bytes) haben.

Daher gibt es eine Vorgabe, wie groß die Nutzrate eines Paketes sein darf, damit diese Nutzrate + Overhead (Angaben die für die Übermittlung notwendig sind) am Ende noch in den PPPoE Frame (1492 Bytes) passen.

Wenn das System die Pakete aber schon in maximale Größe für PPPoE verpackt gibt es dann Probleme, wenn die durch einen VPN sollen, wo es nochmal Overhead gibt.

Einfach:
Du kannst über dein Paketdienst maximal 1kg schwere Pakete versenden. Nun packst du ein Paket welches genau 1kg schwer ist und gibst es bei eurer Poststelle ab.

Damit niemand in dein Paket schauen kann und um es zu schützen (Verschlüsselung), verpackt die Poststelle (VPN) das Paket aber auch nochmal in ein anderes Paket.

Hierdurch wird aber alles schwerer und beim Paketdienst liegt nun ein 1,1kg schweres Paket, was der nicht mitnimmt (garkeine Übertragung auf dem VPN). Um es doch mitzunehmen, Paket er die Pakete aus und verteilt den Inhalt auf 2 Pakete. Eines ist 1kg schwer und das andere nur 100g.

Das 100g Paket nimmt aber den gleichen Platz weg wie das 1kg schwere, also kannst du weniger Inhalt versenden. Abgesehen davon, dauert der gesamte Vorgang auch noch Zeit.

[#10]

Die Paketgrößen hatte ich auch reduziert (zuletzt bis auf 1392, aber das war auch keine hilfreiche Idee. Es änderte nichts an der Performance) Zur Gegenprobe habe ich die MTU wieder auf 1500 gestellt und dann einen Wifi-Hotspot übers iPhone LTE benutzt. Sofort gab es super Datendurchsatz. Gut 1000KB/s. Über die Telekom Verbindung - wohl gemerkt nur im VPN - läuft es mit mageren 10KB/s.

An jedem anderen Anschluss läuft es. Nur an diesem Deutschland LanIP Business-Teil nicht. 

Laut der polnischen Admins handelt es sich um eine reine Client-Server-Geschichte. Das heisst, wenn der Client es schafft is Internet zu kommen und Port 443 aufzumachen, dann gibt es für gewöhnlich keine Probleme. Ich habe folgendes in einer mir völlig fremden Studenten-WG im MehrfamilienHaus der Firma ausprobiert.

1. Laptop auf

2. Forticlient downloaden (Zugagsdaten eingeben)

3. MLM Software der Firma downloaden (Zugangsdaten eingeben)

4. Warenbestand mittels dieser Software downloaden (in 7 Sekunden erledigt)

Der Warenbestandsdownload dauert 1:10 Minuten hinter dieser Digitalisierungsbox Premium, obwohl sie mit 50 Mbits Down und 10 Mbits Upload stabil im Netz klemmt. Der FTP-Download aus Polen ist auch super performant. Ich vertsehe es einfach nicht...

[#11]

Eine MTU von 1500 kann im DSL nicht richtig sein.

Kannst du den Server mit dem Warenbestand bei aufgebautem VPN pingen

Dann Ping mal mit der Option -f -l xxxx die Ip des Servers.

xxxx ersetzen durch einen Wert in Byte der gewünschten Paketgrösse.

was ist die maximale Größe bei der keine Fehlermeldung 

Packet needs to be fragmented but DF set.

kommt?

Hier gibt es ja auch Diskussionen mangelnde Geschwindigkeit.

https://forum.fortinet.com/m/tm.aspx?m=140464&p=

Das einzige was du dann noch machen kannst ist auf dem gleichen Rechner auf dem der VPN Client läuft wireshark zu installieren und den Netzwerk Traffic mitzuschneiden.

[#12]

@Perfumi

Es fehlen doch alle wichtigen Infos:

Firmware-Version von der Digibox?

Anzahl Clients?

Verbindung per LAN oder WLAN?

Ist in der Digibox etwas spezielles konfiguriert was nicht Standard ist: VPN, Firewall, QoS, o.ä?

Hängt die Digibox direkt am VDSL-Anschluss oder ist ein Modem dazwischen?

Zum Debuggen tracet man in der Digibox die gewünschten Schnittstellen und schaut sich das Ergebnis mit Wireshark an. Zusätzlich läßt man sich das Log auf einen Syslog Server schicken. Damit hat man dann alle Infos und braucht nicht wild spekulieren.

[#13]

---

@Stefan schrieb:

Eine MTU von 1500 kann im DSL nicht richtig sein.

Kannst du den Server mit dem Warenbestand bei aufgebautem VPN pingen

Dann Ping mal mit der Option -f -l xxxx die Ip des Servers.

xxxx ersetzen durch einen Wert in Byte der gewünschten Paketgrösse.

was ist die maximale Größe bei der keine Fehlermeldung 

Packet needs to be fragmented but DF set.

kommt?

Hier gibt es ja auch Diskussionen mangelnde Geschwindigkeit.

https://forum.fortinet.com/m/tm.aspx?m=140464&p=

---

Der thread hat doch nichts mit dem Problem hier zu tun. Dort geht es um Fortinet Hardware und IPSEC VPN. @Perfumi spricht von Port 443 und das dürfte dann der SSLVPN client sein.

[#14]

@Micknik

das mit dem Port 443 hat er aber erst im letzen Beitrag geschrieben, habe ich überlesen, bzw. Schon an meinem geschrieben 

[#15]

Ja genau SSLVPN mittels Forticlient Sowtware.

die Digibox hängt allein am DSL, ohne vorgeschaltetes Modem.

es sind nie mehr als 3 Clients gleichzeitig über diese Software am VPN.

Die Firmware ist die aktuellste vom Telekom-Update-Server (vom 5. Februar 2017) . V.10.1.7.120 IPv6, IPSec, PBX... bei Systemlogik steht 1.7

Die MTU ist bei allen Windows10 Maschinen standardmäßig bei 1500 ... einzig die, virtuelle, angelegte Netzwerkverbindung legt sich der Forticlient mit 1392er MTU an. Da die 1500 nirgendwo anders, also an jedem anderen Anschluss, keinerlei Probleme bereitet, bin ich von dem Lösungsansatz der MTU-Anpassung langsam weg. 

[#16]

@Perfumi

WLAN oder LAN ist immer noch unbeantwortet?
Wird die Verbindung per IPv4 oder IPv6 aufgebaut?
Falls per IPv4 dann könntest Du mal versuchsweise unter Vollzugriff -> LAN -> IP-Konfiguration -> br0 -> TCP-MSS-Clamping aktivieren.

Die Probleme sind aber gerade bei schnellen Leitungen bekannt: SSL Performance

Ansonsten bleibt nur Wireshark und Syslog.

[#17]

Eigentlich war der Testrechner, den ich nutzte immer per Wlan verbunden. Es gab zwar keine Verbindungsprobleme, aber ich habe dann gestern eine LAN-Verbindung daraus gemacht, um Fehlerquellen zu minimieren.

Die Verbindung wird via IPv4 hergestellt. Unter TCP-MSS-Clamping gibt es noch einen Parameter. Dort ist dann 1350 eingetragen. Soll das bei Aktivierung so bleiben?

[#18]

@Perfumi

Einfach ausprobieren. Ich würde erst mit dem Default von 1350 beginnen und wenn das nichts bringt auf 1400 stellen.

[#19]

Schade,

ich habe beide Einstellungen durchprobiert, aber es ändert sich nichts. Es wird nicht schlechter, aber auch nicht besser...

[#20]

So, jetzt haben die polnischen Administratoren eine 1A VPN Verbindung LAN-VPN-LAN bei uns in der Digitalisierungsbox Premium eingerichtet. Konfigurationstechnisch ist die auch einwandfrei. Die VPN-Verbindung ist aber trotzdem noch genauso langsam wie vorher.

Wir haben den Weg der Pakete mal analysiert und unterwegs werden an einer Stelle immer Pakete verschluckt.

Hier mal der WinMTR Diagnosebericht:

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |

|--------------------------------------------- - --|------|------|------|------|------|------|

| digitalisierungsbox - 0 | 463 | 463 | 1 | 2 | 162 | 1 |

| 217.xxx.xxx.68 - 1 | 460 | 459 | 15 | 17 | 211 | 19 |

| 217.xxx.xxx.58 - 0 | 463 | 463 | 16 | 20 | 248 | 25 |

| f-ed8-i.F.DE.NET.DTAG.DE - 0 | 463 | 463 | 24 | 26 | 229 | 33 |

|te0-10-0-5-4.agr41.fra03.atlas.cogentco.com- 31 | 207 | 143 | 0 | 35 | 267 | 33 |

| be3187.ccr42.fra03.atlas.cogentco.com - 27 | 224 | 165 | 0 | 33 | 66 | 33 |

| be2798.ccr42.ham01.atlas.cogentco.com - 0 | 463 | 463 | 40 | 43 | 448 | 46 |

| be2253.ccr21.waw01.atlas.cogentco.com - 1 | 460 | 459 | 53 | 55 | 504 | 54 |

|be2882.rcr21.b016833-0.waw01.atlas.cogentco.com 1 | 460 | 459 | 53 | 56 | 507 | 54 |

| finemedia.demarc.cogentco.com - 7 | 368 | 344 | 58 | 62 | 589 | 64 |

| host-188-xxx-xxx-98.finemedia.pl - 5 | 396 | 379 | 58 | 65 | 549 | 60 |

| host-185-xxx-xxx-2.finemedia.pl - 7 | 368 | 344 | 58 | 61 | 352 | 63 |

Weiß jemand, warum derart viele Pakete an den folgenden beiden Servern verloren werden?:
te0-10-0-5-4.agr41.fra03.atlas.cogentco.com
be3187.ccr42.fra03.atlas.cogentco.com

Wir sind langsam echt verzweifelt, denn diese cogentco-server sind doch meines Erachtens irgendwelche Server mitten auf dem Weg. Wie sollen wir das beeinflussen?

Ich krieg an der Sache echt graue Haare...

[#21]

Hallo @Perfumi,

die Server sind von einem anderen Netzbetreiber. Ich vermute, es liegt am Peering, die Daten gehen an der Stelle verloren wo die Netze zusammengeschaltet sind.

Gruß Jörg D.

[#22]

---

@Perfumi schrieb:

So, jetzt haben die polnischen Administratoren eine 1A VPN Verbindung LAN-VPN-LAN bei uns in der Digitalisierungsbox Premium eingerichtet. Konfigurationstechnisch ist die auch einwandfrei. Die VPN-Verbindung ist aber trotzdem noch genauso langsam wie vorher.

Wir haben den Weg der Pakete mal analysiert und unterwegs werden an einer Stelle immer Pakete verschluckt.

Hier mal der WinMTR Diagnosebericht:

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |

|--------------------------------------------- - --|------|------|------|------|------|------|

| digitalisierungsbox - 0 | 463 | 463 | 1 | 2 | 162 | 1 |

| 217.xxx.xxx.68 - 1 | 460 | 459 | 15 | 17 | 211 | 19 |

| 217.xxx.xxx.58 - 0 | 463 | 463 | 16 | 20 | 248 | 25 |

| f-ed8-i.F.DE.NET.DTAG.DE - 0 | 463 | 463 | 24 | 26 | 229 | 33 |

|te0-10-0-5-4.agr41.fra03.atlas.cogentco.com- 31 | 207 | 143 | 0 | 35 | 267 | 33 |

| be3187.ccr42.fra03.atlas.cogentco.com - 27 | 224 | 165 | 0 | 33 | 66 | 33 |

| be2798.ccr42.ham01.atlas.cogentco.com - 0 | 463 | 463 | 40 | 43 | 448 | 46 |

| be2253.ccr21.waw01.atlas.cogentco.com - 1 | 460 | 459 | 53 | 55 | 504 | 54 |

|be2882.rcr21.b016833-0.waw01.atlas.cogentco.com 1 | 460 | 459 | 53 | 56 | 507 | 54 |

| finemedia.demarc.cogentco.com - 7 | 368 | 344 | 58 | 62 | 589 | 64 |

| host-188-xxx-xxx-98.finemedia.pl - 5 | 396 | 379 | 58 | 65 | 549 | 60 |

| host-185-xxx-xxx-2.finemedia.pl - 7 | 368 | 344 | 58 | 61 | 352 | 63 |

Weiß jemand, warum derart viele Pakete an den folgenden beiden Servern verloren werden?:
te0-10-0-5-4.agr41.fra03.atlas.cogentco.com
be3187.ccr42.fra03.atlas.cogentco.com

Wir sind langsam echt verzweifelt, denn diese cogentco-server sind doch meines Erachtens irgendwelche Server mitten auf dem Weg. Wie sollen wir das beeinflussen?

Ich krieg an der Sache echt graue Haare...

---

Was sagt uns dieser Test jetzt? Nicht viel weil die Pakete laufen ja außerhalb des VPN-Tunnels. Interessant wäre doch nur ein Test im VPN-Tunnel.

[#23]

Ja, wir hatten jetzt Kontakt zu Cogentco. Das hier war im Ergebnis des Telefonates der Kern der Aussagen:

Cogentco Hotline Employee: We have always problems with german telekom. All Peering points are saturated. The bandwith at the peering points is a terrifying problem we are discussing every week with the german telekom. The problem persists until two months and you can do nothing except wait and report further with high pressure. The Packets were not lost due to misconfiguration. They were discarded due to overload of the server bandwith.

He adviced off the records to get in contact with telekom and try to force for a special solution in this individual case or simply to change the provider.

[#24]

@Micknick und wie macht man zuverlässig eine Routenverfolgung im VPN-Tunnel?

eins ist Fakt... mit jeder anderen Internetverbindung ist die Verbindung um ein vielfaches schneller. Kann man das Peering denn garnicht beeinflussen?

[#25]

---

@Perfumi schrieb:

@Micknick und wie macht man zuverlässig eine Routenverfolgung im VPN-Tunnel?

---

 Als Ziel eine Gegenstelle im VPN in Polen angeben.

---

@Perfumi schrieb:

eins ist Fakt... mit jeder anderen Internetverbindung ist die Verbindung um ein vielfaches schneller. Kann man das Peering denn garnicht beeinflussen?

---

Hier widersprichst Du Dir aber selbst. Auf Seite 2 hast Du noch folgendes geschrieben:

@Perfumi schrieb:

Ah, das lässt sich leicht beantworten. Das läuft höchst performant. Es gibt am Firmen-FTP immer einen Ordner mit Media-Dateien für die lokalen Werbemaßnahmen (Flyer/Poster etc.). Das hab ich grad getestet und die Daten fließen mit durchschnittlich 27 Mbit also wirklich super!