Hi @BPMeijer, welkom op het forum!

Vanuit de KPN klantenservice kunnen we hier inderdaad weinig in betekenen, gelukkig zijn er op het forum een aantal hele kundige mensen aanwezig die hier misschien wél iets over te zeggen hebben! @wjb bijvoorbeeld?

En heb je hierover al contact gehad met je werkgever? Wellicht is dit een bekend issue, en kunnen ze je zo vertellen hoe dit op te lossen valt 

Kan je het IP adres van jouw werkgever pingen?

Krijg je daarop ook een tragere response?

Zou het kunnen zijn dat de VPN server van jouw werkgever nu veel zwaarder belast wordt omdat er veel meer mensen noodgewongen thuiswerken?

Het is niet mogelijk om zelf een route te configureren naar de server van jouw werkgever.

Het zou zelfs zo kunnen zijn dat er meerdere routes gebruikt worden afhankelijk de load op bepaalde routes.

Bedankt voor de reacties. @wjb Ik heb het IP adres zonder VPN (10 ms) en met VPN (225 ms) gepingt, dat geeft een duidelijk verschil, maar op dit moment lijkt alles goed te werken. Het gekke is dat de performance is de afgelopen dagen overdag prima, maar vanaf circa 18:00 lijkt het dat de routering wijzigt, en dan heb ik een enorme latency. Ik zal dezelfde test ook nog eens doen als de verbinding weer heel traag is. 

Ik heb al uitgebreid met een zeer kundige IT collega naar gekeken, we hebben de performance via mijn laptop met VPN en via remote desktop zonder VPN met elkaar vergeleken → dat duidt erop dat het probleem in de verbinding met VPN ligt. De performance is de laatste dagen juist 's avonds heel slecht, ik verwacht dat er na 20:00 beduidend minder thuis gewerkt wordt dan overdag. Daarmee is de belasting van de VPN server denk ik ook uitgesloten? 

Is er een schema van routering of wordt dat automatisch gewijzigd afhankelijk van de load op knooppunten en routes?

Ga er maar vanuit dat routering continue wordt aangepast aan de hand van allerhande factoren. Load/drukte op een bepaald dagdeel is meest voor de hand liggend, maar in extreme gevallen ook gewoon keihard geld van de ene of andere (tussenligggende) partij. Wordt dan als soort van pressiemiddel ingezet, is bekend fenomeen van o.a. Deutsche Telekom. Je kan m.b.v. traceroutes en ASN databases misschien wel wat duidelijker krijgen wat er aan de hand is, maar blijft hoop gissen en is niet zo triviaal.

Sterker nog: Als het IP adres via je KPN verbinding wel met een goede snelheid te pingen is en over de VPN niet, dan heb je zelfs een goede kans dat het probleem bij de VPN provider / configuratie ligt en niet bij KPN. Misschien ook eens een ticket aanmaken bij de VPN provider?

@TFHFony net nog een keer geprobeerd, nu via VPN ook 11 ms. Het is lastig dat de verbinding niet stabiel is, dat is het hele probleem Bedankt voor je reactie! 

Er is geen sprake van een VPN provider, de VPN verbinding wordt met de VPN server van de werkgever opgezet.

In principe zou de routering tussen thuisnetwerk en de werkgever ook geen onderscheid kunnen maken of het nu verkeer binnen de VPN betreft of daarbuiten. De oorzaak zou mijns inziens dan ook binnen de VPN tunnel gezocht moeten worden.

Is er sprake van split-tunneling of wordt al het verkeer via de tunnel geleid?

Je zou dit kunnen controleren door via whatsmyip.org jouw publieke IP adres op te vragen.

Is dat jouw "gewone" publieke IP adres van KPN of die van jouw werkgever?

You're welcome ;-)
Mocht je het IP adres weten van de VPN server waarmee je verbindt zou je een ping kunnen uitvoeren naar die VPN server op het moment dat het zo traag gaat (Wel als je gaat pingen, even de VPN uitzetten). Als je ping naar de VPN server dan wel laag is, maar de verbinding naar je bedrijfsnetwerk wel traag, dan zit de oorzaak aan de kant van de VPN provider.

Ik weet niet of je bekend bent met de command prompt, maar je zou het tracert commando kunnen gebruiken. Op het moment dat e.e.a. traag gaat zou je eens een tracert naar het IP adres van de VPN server doen (natuurlijk zonder dat de VPN draait) en daarna een tracert naar een server van je werk (terwijl de VPN draait). Dan kan je zien waar de vertraging optreed.

Tracert gebruik je door naar de opdrachtprompt te gaan en dan TRACERT te typen, gevolgd door de URL of het IP adres van de gewenste server.

Een trace route geeft geen goede inzage in de plek waar de vertraging optreedt.

Alleen als alle hops achter een hop met een hogere responsetijd ook een hogere responsetijd geven kan dat een indicatie zijn van congestie.

Als de responsetijden in een achterliggende hop weer lager zijn dan zeggen hogere responsetijden bij eerdere hops alleen maar wat over snelheid van afhandeling van ping requests door de hop zelf. Het is heel terecht dat hops een lage prioriteit geven aan het afhandelen van ping requests om zo alle "aandacht" te kunnen richten op de taak waarvoor ze er staan en dat is routeren van data.

Klopt… maar gezien de klachtomschrijving is er een gewoon best een goede kans dat je bovenstaande (een punt waarvan af alle hops er na een hogere responsetijd geven) tegen zal komen. Wellicht een punt in de routing welke overbelast is.

Ik weet ook wel dat ICMP packages met een lagere prioriteit worden afgehandeld of zelfs worden gedropt. Maar tracer route kan toch een zeer handige tool zijn.

Het oplossen van het probleem wordt een stuk lastiger omdat er een goede kans is dat deze congestie plaats vindt buiten het netwerk van je eigen ISP.

Ik verwacht het niet immers dan zou je dat zowel met als zonder die VPN verbinding ervaren.

Er is immers niets anders aan de route in die twee gevallen.

Bedankt voor alle reacties! Ik heb vanmiddag (toen alles nog prima werkte) een tracert gedaan (met VPN). Sinds circa 17:00 is de verbinding weer enorm langzaam, ik heb toen direct weer een tracert gedaan (met VPN) en zonet nog een keer eentje zonder VPN. Het lijkt er op dat de verbinding bij IP adres 139.156.98.100 (Amsterdam?) en 149.6.139.138 (Düsseldorf?) een time out heeft. Dit is in beide tests (met en zonder VPN) het geval. Zou daar het probleem dan kunnen zitten? 

Zie de afbeelding voor de resultaten. Kan iemand hier chocola van maken? Kan ik nog meer testen? Bedankt!!!  :)

De timeouts bij die hop zijn niet echt een probleem. Dit soort servers zijn zo geconfigureerd om normaal verkeer als eerste door te laten en als er tijd over is te reageren op ping requests. Zolang er geen drops plaats vinden na zo'n hop is er niets aan de hand.

Kijkend hier naar deze tracerts blijft eigenlijk de latency onder alle gevallen OK. Ik ben wel benieuwd om deze tracerts te zien als je wel vertraging ondervind. Als dan zonder VPN de latency goed blijft en met VPN al vanaf het begin van de tracert hoog, dan zit het probleem waarschijnlijk in de VPN (of het intranet) van je werk.

Zit er zonder VPN ineens een grote sprong in latency ergens in de tracerroute, dan zit het probleem in de router KPN → VPN/Werkgever.

@TFHFony de onderste 2 tracerts zijn (met en zonder VPN) gedaan terwijl ik vertraging ondervind (as we speak). Dus als je zegt dat het daar niet aan ligt, waar ligt het dan aan? Het bedrijfsnetwerk? Daar zou het volgens mijn IT collega niet aan liggen...maar dat zou ik denk ik ook zeggen, als ik hem was ;)

Er lijkt helemaal niets mis te zijn met de verbinding naar jouw werkgever.

Mijn vermoeden is dat dit probleem binnen het netwerk van jouw werkgever gezocht moet worden.

Heb je split-tunneling of niet?

Als je split-tunneling hebt, heb je dan alleen vertraging rchting services van jouw werk of merk je dat ook bij andere diensten op Internet?

@wjb Ik denk dat ik geen split-tunneling heb (ik heb er alleen niet zo veel verstand van ).  De vertraging is nu al het hele weekend en is momenteel (met VPN) zowel richting services van mijn werk (applicaties, netwerkschijven), maar ook bij andere diensten (we hebben bijvoorbeeld een ESRI web-omgeving die we ook zonder VPN kunnen benaderen, die web-omgeving is nu ook heel traag via VPN).  Ik kan de services van mijn werk natuurlijk niet zonder VPN testen, maar onze ESRI omgeving is zonder VPN wel gewoon snel (zoals ie altijd is). Dat lijkt dan dus toch aan de VPN te liggen? 

Als ik (met VPN) een speedtest doe, dan heb ik wel gewoon 6 ms ping en 200 Mb down en 400 Mb up (foutje in de configuratie? Zou symmetrisch moeten zijn, toch? ). De verbinding zelf is dus snel genoeg. 

Als ik een tracert of een ping test doe (met VPN) direct naar de url van een van de applicaties van mijn werk, dan zie ik enorme verschillen in de latency, uiteenlopend van 22 ms tot 3393 ms, of soms een *. Is dat dan het bewijs dat de verbinding tot aan onze servers niet het probleem is (zie tracert tests in vorige post), maar de VPN tunnel er naartoe? Ik heb (gelijktijdige parallel test met iemand die op kantoor werkte) al uitgesloten dat de services/applicaties zelf slecht performen. Dan dus toch een slecht presterende VPN?  

Het lijkt er wel op…. Zeker gezien het wisselt, lijkt het er op dat er gewoon op dat op bepaalde momenten de boel volloopt. Als het een routing issue was, dan zou je het probleem namelijk continu zien. Routes zijn op zich niet 100% statisch, maar wisselen ook niet continu.

Waarschijnlijk gaat dit probleem dus pas voorbij zijn als er weer wat minder thuisgewerkt gaat worden.]

Zou je trouwens wel eens zo'n tracert met zo'n hoge waarde hier willen posten? Liefst een keertje met als zonder VPN (als URL uberhaupt te bereiken is zonder VPN).

Noteer jouw publieke IP adres terwijl je geen VPN verbinding actief hebt.

Doe hetzelfde terwijl je wel een VPN verbinding actief hebt.

Zijn die twee publieke IP adressen hetzelfde of wijken ze af van elkaar?

(Niet die publieke IP adressen hier vermelden!)

Je kunt jouw publieke IP adres via https://www.whatsmyip.org opvragen.

@TFHFony  tracert zonder en met VPN naar onze ESRI server (die dus ook zonder VPN bereikbaar is, daar had ik tot vandaag niet aan gedacht )

Het probleem ligt dus overduidelijk binnen de VPN en dat ligt buiten de invloedssfeer van KPN.

Je zult dit toch echt met jouw ICT afdeling op moeten nemen.

Hartelijk dank voor de hulp en de antwoorden!! Ik ga mijn collega morgen bestoken met de resultaten van deze tests 

En zo zie je dat je aan een tracert soms dus WEL kan zien waar het probleem ligt ;-)

@BPMeijer : Succes met het lastigvallen van je ICT collega's! :)

Heb je ook nog gekeken naar die publieke IP adressen met en zonder VPN?

Als die twee verschillend zijn dan is er geen sprake van split tunneling en loopt alle communicatie door de VPN tunnel (ook een speedtest).

Blijft het IP adres echter gelijk, dan is er sprake van split tunneling en zal veelal alleen de communicatie richting servers van jouw werkgever via de VPN tunnel lopen.

Zoals ik al zei …

Ja, sorry, had even deze post gemist . Maar dat heb ik ook getest. Beide IP adressen zijn gelijk.