IPsec over Compal Connectbox == hoge ping

[Francesco]

Hallo,

Na flinke problemen door een slechte kabel, die nu enige tijd geleden opgelost zijn met een nieuwe grondkabel, is mijn verbinding stabiel, en krijg ik meestentijds een goede download snelheid.

Ik heb echter gemerkt dat de verbinding alsnog problemen heeft wanneer ik data over een IPsec site-to-site verbinding verstuur (vzv ik kan zien zowel upload als download), en dat begint al bij een paar Mbps bandbreedte.

Als ik via de VPN werk gaat de ping snel omhoog tot 500+ ms, en stort de verbinding effectief in.

Ik heb parallel aan de modem een RasPi verbonden met een 192.168.100.x adres, en ik ping zowel de AMSIX router als de RasPi met SmokePing.

De RasPi blijft ten alle tijden tussen 300us en 700us, maar de AMSIX Router gaat van 8ms-16ms naar 500-700ms als IPsec enigszins belast wordt (zoals ik al zei, een paar Mbps is al voldoende, en nowhere near de 300Mbps van de verbinding!)

Gisteren rond 21:20 heb ik een 115MB groot bestand gedownload, en dat duurde ong. 5 minuten door de verhoogde latency en tijdelijke network stops die daardoor optreden:

Tegelijkertijd doet de RasPi ping niets anders dan anders:

Dat geeft dus aan dat het niet de Firewall/VPN is, maar ergens tussen mijn lokale firewall en de remote firewall! En omdat niet alleen de VPN er last van heeft, maar het hele Internet verkeer, kan het alleen nog maar liggen in de Compal box, de CMTS of het er achter liggende netwerk van Ziggo.

Ik kan me niet herinneren dat vóór ik de kabel problemen had, ik ooit dit soort gedrag gezien heb, maar inmiddels heb ik 3x een ander modem (de laatste keer verwisselt van Arris naar Compal) en is Ziggo ook bezig met migreren van EuroDocsis 3.0 naar Docsis 3.1...

Ik zag een ander topic van begin 2020, en daarin werd óók gesproken van 500ms ping en een site-to-site verbinding, dus ik vraag me ondertussen af of Ziggo (hetzij in de modems, hetzij in de CMTS of elders in hun netwerk) problemen heeft met IPsec verkeer?

[Bert]

Om je huidige signaal te kunnen beoordelen, kun je hier uit je modem de volledige pagina's van downstream en upstream waarden plaatsen met een schermafbeelding en de laatste dagen Netwerk historie?

Waar vind ik de up- en downstreamwaardes van mijn modem?

https://community.ziggo.nl/t5/Tips-van-Ziggo/Waar-vind-ik-de-up-en-downstreamwaarden-van-mijn-modem/...

En kun je een foto hier plaatsen van de eerste plaats waar Ziggo je huis binnenkomt met eventuele splitters en versterkers op de foto?

[Francesco]

Dat kan, maar hoe is dat relevant als alleen wanneer IPsec actief over de verbinding loopt, de ping oploopt?

En de hele installatie is door de Group Go medewerkers vernieuwd en doorgemeten toen ze de grondkabel vervangen hebben, dus dat is allemaal nieuw en in orde. (Zie ook mijn oude thread...)

Tests geven gewoon  ~300M down en ~30M up... En ook tijdens de snelheids testen blijven de ping tijden acceptabel, maar zodra er een paar Mbps IPsec door gaan is het bal!

Het is dus m.i. niet aan signaal niveaus gerelateerd (het signaal ziet geen verschil tussen RTSP, FTP of IPsec), dus wil ik ook dit topic niet vertroebelen met irrelevante screenshots

[Bert]

"Tests geven gewoon  ~300M down en ~30M up... "

"Het is dus m.i. niet aan signaal niveaus gerelateerd"

De snelheidstest zegt in het geheel niets over de fijnmazige kwaliteit van je verbinding.

Het modem heeft een overcapaciteit en als er ergens een kanaal niet geheel lekker werkt, door een haperende verbinding, dan neemt een ander kanaal dit over, zonder dat je dat in je snelheidstest merkt.

Maar als je alle pakketten bekijkt, dan kunnen er makkelijk een aantal wel te corrigeren en een aantal niet te corrigeren pakketen tussen zitten en dat zie je wel degelijk in fijnmazige tests.

Deze zijn in je modem te zien als Pre RS Errors en Post RS Errors of fouten voor RS en Fouten na RS.

IPsec problemen zie ik hier maar zelden langskomen.

Aan jouw de keuze, in ieder geval succes gewenst met het zoeken naar je oplossing.

[Jiri]

Hallo @Francesco

Wat raar dat de ping bij het versturen/gebruiken van Ipsec (ik moet je eerlijk bekennen dat ik hiermee niet bekend ben) de pan uit reist.

Voor het uitzoeken waar dit probleem precies vandaan komt, starten we altijd bij het signaal op het modem. Dit is dan ook de reden dat @Bert naar jouw aansluiting en de waardes van het modem vraagt. Ik heb het vanaf hier bekeken en kan niet anders concluderen dan dat het signaal prima is. Het probleem kan hier niet vandaan komen. 

Rest ons nog het modem en alles wat daar achter hangt. De enige manier om uit te sluiten of de problemen vanuit het modem of juist daarachter komen is door het rechtstreeks op het modem te testen. Wil je dit eens proberen en de resultaten met ons delen? 

Kun je uitleggen wat voor handelingen je uitvoert om IPSec te gebruiken?

[Francesco]

Mijn firewall (direct aangesloten op het modem) heeft een IPsec site-to-site VPN naar meerdere andere firewalls. Deze VPNs zijn always-up, maar zolang er geen significante hoeveelheden verkeer over gaan, merk ik daar niets van.

Wanneer ik echter iets up- of download, en het verkeer een paar Mbps bereikt (10Mbps is al ruim voldoende daarvoor, en het is lastig te testen hoeveel precies, maar ook met minder verkeer dan dat zie ik het al gebeuren) gaat de ping latency naar buiten als een gek omhoog naar 500-700ms, terwijl de lokale ping door de firewall (naar die RasPi parallel aan het modem) gewoon laag blijft!
(Ik kan overigens het modem helemaal niet pingen op 192.168.100.1, terwijl ik wel uitgaande ping pakketten zie als ik capture op de firewall WAN poort, maar kan wel de WebUI bereiken!)

[Francesco]

Verdere tests die ik zojuist heb uitgevoerd (Ik heb zojuist bijv een 4GB bestand gedownload van een site @ 80-100Mbps) LIJKEN er op te wijzen dat alleen de VPNs waarbij NAT-T gebruikt wordt dit probleem veroorzaken...

IPsec is normaal gesproken een apart protocol onder IP (IP Protocol 50, met dan nog poort 500 voor control traffic, ie sessie set-up, enz.), maar als er (1x of meer) NAT tussen de IPsec peers plaatsvindt, werkt IPsec niet meer, en daarvoor hebben ze NAT-Traversal (NAT-T) bedacht. Hierbij wordt het IPsec verkeer geencapsuleerd in UDP pakketten op poort 4500.

VZV ik NU kan zien, werkt gewoon IPsec (IP/50) zonder problemen, maar veroorzakt IPsec-NAT-T (dus feitelijk UDP/4500) verkeer de geobserveerde latency problemen.

Uiteraard heb ik geen controle over de NAT status van de end-points, en is (ook uiteraard) de endpoint die ik het meeste gebruik een van de endpoints waarbij NAT-T onvermijdelijk is...  😞

[Francesco]

Ik heb de IPsec VPN naar die ene NAT-T lokatie vervangen door een OpenVPN TCP tunnel (gelukkig heb ik die mogelijkheid voor die lokatie!), en dat werkt wel probleemloos.

Dat betekent dus dat mijn onmiddelijke probleem opgelost is, maar het blijft vreemd dat UDP/4500 zoveel problemen oplevert en TCP/1194 (en vzv ik kan zien alle andere TCP verbindingen alsook IPsec/ESP [IP/50]) niet...

Ik vraag me af of andere UDP verbindingen óók problemen zouden opleveren, maar weet nu even niet zo snel hoe ik dat zou kunnen testen!

[Francesco]

Testen met iPerf3 tegen een publieke server @ 300Mbps UDP in beide richtingen (waarbij ik dus 90% oversubscriptie verwacht op het modem voor upstream, maar iPerf heeft niet de mogelijkheid voor up en down aparte snelheden te definieren) heeft wel een IETS hogere ping latency (van ong 10-15ms naar 25-30ms) maar niet de absurde waardes van 500-700ms...

Heel vreemd dus dat IPsec/NAT-T (UDP/4500) dat effect WEL heeft bij veel lagere bandbreedte behoefte!

Als iemand een idee heeft om te testen hoor ik het graag, maar met de primaire NAT-T VPN nu over op OpenVPN via TCP/1194 ben ik geholpen...

(PS: De UDP iPerf test gaf 298/30.9 Mbps als performance over 2GB data, en dat is *met* achtergrond verkeer, dus ik ben tevreden met de snelheid die ik krijg!)

[Lotte]

@tobiastheebe Kun jij hier misschien bij helpen?