Skip to main content
Na de overgang van van het wifi netwerk in de trein van T-mobile naar WiFi in de trein, is het mij en collegaas niet meer gelukt om een VPN verbinding naar ons bedrijf over het wifi netwerk op te zetten. Dit maakt het werken in de trein een stuk minder efficient, omdat het niet mogelijk is om bijvoorbeeld (bedrijf) email op te halen of te versturen, daar de email server alleen via VPN te is bereiken.



Kan NS er weer voor zorgen, dat VPN verbindingen zonder problemen opgezet kunnen worden, net zoals bij T-mobile het geval was.

Trajecten: Utrecht-Zwolle, Zwolle-Groningen.

Protocolen: VPN #1: pptp, VPN #2: OpenVPN (UDP, poort 1194).



Op beide trajecten kan met geen van beide VPNs verbinding worden gemaakt.



Tijdens verbinding met pptp:



Sent control packet type is 1 'Start-Control-Connection-Request'

Received Start Control Connection Reply

Client connection established.

Sent control packet type is 7 'Outgoing-Call-Request'

Received Outgoing Call Reply.

Outgoing call established (call ID 0, peer's call ID 29004).

...

VPN connection '** censored **' (IP Config Get) timeout exceeded.



Met OpenVPN:



VPN connection '** censored **' (Connect) reply received.

...

VPN connection '** censored **' (IP Config Get) timeout exceeded.
ah eerst Drenthe en nu is Utrecht-Apeldoorn ook al de wildernis in Nederland ?



Maar Tom NS, waarom waren daar eerder dan geen problemen ? Zijn er een aantal GSM masten afgebrand recentelijk ?



Het probleem speelt nu min 5 maanden.
Op dit moment spelen er nog een aantal uitdagingen rondom VPN verbindingen. Het blijkt dat bepaalde typen VPN verbindingen niet tot stand komen ondanks het feit dat er niets geblokkeerd wordt. Er loopt een onderzoek waarbij de connectiviteit van de gehele keten tussen trein en internet wordt onderzocht om de bottleneck te vinden.



Daarnaast is het ook locatie afhankelijk. Bijvoorbeeld het traject Utrecht-Apeldoorn kent vele plekken waar zeer slechte GSM dekking is. Doordat de connectie van de trein naar het internet ook via het GSM netwerk loopt heeft dit directe invloed op de kwaliteit. Daarnaast heeft het GSM netwerk de eigenschap dat spraak voor data gaat waardoor als eerste de dataverbinding weg valt.



Om de connectiviteit te verbeteren lopen er verschillende projecten, hierbij moet je bijvoorbeeld denken aan het vervangen van hardware op de trein en optimaliseren van het dataverkeer tussen trein en internet.



Wij adviseren absoluut het gebruik van VPN verbindingen en daarom heeft dit onze volledige aandacht.
Ook jij bedankt voor je toevoeging Giovanni. Als er nieuws is, laat ik dat hier weten.



Geen nieuws van TomNS
Beste GJF, dank voor je feedback. Ik neem je verhaal mee naar de beheerder van het netwerk en laat z.s.m. zijn reactie weten!
Beste jvanraaij, bij de overgang van WiFi van t-mobile naar WiFi in de Trein zijn er tijdelijk een paar poorten gesloten geweest. Inmiddels zijn er geen poorten meer gesloten. Om het netwerk niet overbelast te laten raken, is er wel voor gekozen om streaming media te blokkeren.

In theorie moet er dus gewoon weer met VPN gewerkt kunnen worden. Echter spelen er nog twee zaken: Ten eerste blijft het functioneren van het netwerk afhankelijk van de netwerkdekking aan de hand van zendpalen. Wanneer een trein dichtbij een mast rijdt, is de dekking beter en zal het WiFi beter werken. Ten tweede is het aantal gebruikers van WiFi in de Trein en de vraag naar bandbreedte erg gestegen, waardoor het stukje van de taart dat je als 'single user' krijgt steeds kleiner wordt.

Dit is de reden waarom we hebben besloten om iedere gebruiker een evenredig deel van de taart te geven. Dit zal binnenkort uitgerold worden.




Helaas Tom...



VPN werkt niet in de ICMm's tussen Utrecht Centraal en Apeldoorn.



Gebruikte protocollen zijn:



- IPSec Xauth PSK naar een FRITZ!Box die direct aan het internet hangt;

- PPTP naar een Linux-server achter NAT (achter bovenstaande FRITZ!Box).



Op andere WiFi's (Syntus/ander open WiFi access point) en via 3G (Vodafone) werken béide systemen wel.



Tijdens het proberen te initialiseren van de VPN's kon ik overigens wel probleemloos op internet. En niet eens langzaam ofzo. Het was ook vroeg/rustig in de trein. Dus het hele verhaal over bandbreedte en taartstukjes lijkt me irrelevant.



Overigens raden jullie nog steeds aan VPN's te gebruiken i.v.m. de veiligheidsrisico's van een open WiFi accesspoint. Hoewel ik dit zéér goed vind (veel open WiFi accesspoints melden dit niet eens), vind ik het vervolgens zéér kwalijk als je geen VPN kunt initialiseren :@



Hoewel 't een gratis service is, verwacht ik eerlijk gezegd op zeer korte termijn wel een oplossing hiervoor, want dit kan zo echt niet langer. Vooral gezien de lange tijd dat dit nu al speelt en de claims die jullie zelf maken op de pagina's die je in de trein voorgeschotelt krijgt. Op z'n minst een inhoudelijk antwoord wat verder gaat dan "We zijn er mee bezig".
Beste jvanraaij, bij de overgang van WiFi van t-mobile naar WiFi in de Trein zijn er tijdelijk een paar poorten gesloten geweest. Inmiddels zijn er geen poorten meer gesloten. Om het netwerk niet overbelast te laten raken, is er wel voor gekozen om streaming media te blokkeren.

In theorie moet er dus gewoon weer met VPN gewerkt kunnen worden. Echter spelen er nog twee zaken: Ten eerste blijft het functioneren van het netwerk afhankelijk van de netwerkdekking aan de hand van zendpalen. Wanneer een trein dichtbij een mast rijdt, is de dekking beter en zal het WiFi beter werken. Ten tweede is het aantal gebruikers van WiFi in de Trein en de vraag naar bandbreedte erg gestegen, waardoor het stukje van de taart dat je als 'single user' krijgt steeds kleiner wordt.

Dit is de reden waarom we hebben besloten om iedere gebruiker een evenredig deel van de taart te geven. Dit zal binnenkort uitgerold worden.
Beste jvanraaij, ik heb Tom NS gevraagd om hier zo snel mogelijk antwoord te geven.
Hallo Tom NS,



Bedankt voor de update, dat maakt het voor een deel duidelijker.



Vijf punten/vragen:

1. Waarom heb je jouw bericht niet direct in dit topic gezet?

2. Er ontbreekt nog een stukje: waarom werkte VPN eerst wel, nu niet? Is dat omdat al het UDP verkeer geblokkeerd wordt om streaming te voorkomen?

3. Je zegt niets over een VPN die weer zou werken in de proef, kun je bevestigen dat het maken van een VPN verbinding wel mogelijk is binnen de proef?

4. Wat is de status en planning van de proef?

5. Is het mogelijk deel te nemen aan de proef?
Werken in de trein kan helaas niet. Gewoon internet is veel te traag en VPN werkt helemaal niet. Erg jammer:(
Beste Gany, ik had inderdaad graag gezien dat de berichtgeving rondom dit onderwerp wat gestroomlijnder naar buiten was gekomen, dat was voor iedereen plezieriger en helderder geweest.



Er wordt momenteel getest met het verstrekken van een persoonlijke bandbreedte. Het komt er daarbij op neer dat iedere WiFi-gebruiker 100 kB krijgt toegewezen. Hierdoor wordt de bandbreedte gelijkmatig over de gebruikers verdeeld, waardoor wordt voorkomen dat een enkeling een groot deel van het netwerk opeist. Wanneer deze proef succesvol blijkt, zal landelijke uitrol volgen.
Beste Tom,

de informatie op Twitter doet vermoeden dat er wel meer informatie beschikbaar is. Wellicht is de teleurstelling beter te managen wanneer er zorg wordt gedragen dat beide communicatie lijnen hetzelfde verkondigen op hetzelfde moment.



Buiten bovenstaande feedback, op de lijn Enkhuizen - Amsterdam is zowel tijdens de spits als buiten de spits het internet via wifi bijzonder slecht. Zelfs een berichtje via whatsapp is vrijwel onmogelijk. Gebruik maken van een VPN connectie is geheel onmogelijk. Dit is ook op de tijdstippen dat er bij wijze van spreke : meer conducteurs dan reizigers in de trein zitten.



Dit was aanzienlijk beter toen de service werd verleent door T-Mobile. Al ben ik blij dat deze problemen niet uniek zijn, ben ik uitermate benieuwd hoe en wanneer deze problemen opgelost worden.

Immers; het mag dan wel een extra dienst zijn, verkapt zit het echt wel in het vervoerstarief.



Groetend,



Gany
Helaas vormt dit ook een probleem voor mij,



Ik reis op het traject Leeuwarden - Den Haag Centraal en helaas is het niet mogelijk om een VPN verbinding te maken. Dit maakt het werken in de trein minder betrouwbaar i.v.m betrouwbare gegevens.



Hopelijk snel een oplossing!



Ik maak gebruik van VPN via PPTP.
Ik kan mij ook in de bovenstaande berichten vinden. Ikzelf heb een OpenVPN server thuis draaien. In de begindagen van de WiFi in de treinen (in de VIRMs dan wel), kon ik prima verbinding maken en internetten via de VPN verbinding. Echter na enige tijd (tot de dag van nu) is het nog mogelijk verbinding te maken met de server, in de trein, maar daadwerkelijke internet toepassingen zijn onmogelijk geworden, alsof er niet genoeg bandbreedte is...
Zelfde probleem hier. Gaat om een VPN-verbinding met mijn Synology via PPTP. Ik reis vaak tussen Amsterdam-(Almere en Amersfoort)-Groningen en Amsterdam-Deventer. Heb nog nooit een VPN-verbinding tot stand kunnen brengen in de trein, en heb met andere verbindingen nooit problemen met mijn VPN.
Ik ondervond inderdaad ook het probleem dat met de wijziging van T-Mobile naar ‘WiFi in de trein’ mijn VPN geen verbinding meer maakte, maar heb dat probleem opgelost door te kiezen voor een ander data transfer protocol.



Mijn dataprotocol was UDP, maar staat nu op TCP. Dat werkt wel. Waarschijnlijk is dat overigens überhaupt een betere instelling in de trein, omdat de verbinding als het goed is stabieler is bij TCP dan UDP.



Lost dat de problemen op? Wellicht kun je in je VPN software twee verschillende profilen aanmaken: één voor UDP en één voor TCP.
Ik ondervind dezelfde problemen: geen VPN verbinding in de trein mogelijjk. Op hetzelfde moment wel via het Vodafone netwerk en via andere WiFi spots.



Mijn VPN server zit op het Ziggo netwerk en ik gebruik het PPTP protocol.



Vr.gr.



Om wat gerichter te kunnen onderzoeken wat er aan de hand is hebben de technici wat meer info nodig. Kan je ons helpen op een antwoord op onderstaande 2 vragen?



- Naar welke omgeving wordt een VPN sessie wordt opgebouwd (IP range, SaaS dienst)

- Welk protocol wordt gebruikt



Of heb je een beschrijving van hoe je je aanmeldt op je netwerk? Via welke url gaat dit? We horen het graag!

Ik heb het zelfde probleem VPN verbingdingen via diverse protocollen en naar verschillende locaties krijg ik geen een VPN verbinding aan de praat. Dit maakt werken in de trein zwaar waardeloos aangezien ik nu niks kan doen.



NS kan maar beter richten op het laten rijden van treinen en ict aan een fatsoenlijk bedrijf overlaten.
Voegt mogelijk vooralsnog niet veel toe maar ik ervaar exact dezelfde problemen als genoemd door

"Forenz" sinds dat het wifi netwerk in de trein van T-mobile naar WiFi in de trein is overgegaan
Ook jij bedankt voor je toevoeging Giovanni. Als er nieuws is, laat ik dat hier weten.
Edit: Perongelijk een dubbel post gemaakt.
Ook ik kan al een tijdje geen verbinding meer maken via VPN, ik gebruik 'Cisco IPSec' pingen naar de vpn server gaat overigens wel goed.



Dit staat er in de logs (IP nummer weggehaald):



26/06/14 09:12:16,826 configd[18]: IPSec connecting to server XXX.XXX.XXX.XXX

26/06/14 09:12:16,829 configd[18]: network changed.

26/06/14 09:12:16,830 configd[18]: IPSec Phase1 starting.

26/06/14 09:12:16,831 configd[18]: SCNC: start, triggered by (174) SystemUIServer, type IPSec, status 0, trafficClass 0

26/06/14 09:12:16,898 racoon[19779]: accepted connection on vpn control socket.

26/06/14 09:12:16,899 racoon[19779]: IPSec connecting to server XXX.XXX.XXX.XXX

26/06/14 09:12:16,899 racoon[19779]: Connecting.

26/06/14 09:12:16,899 racoon[19779]: IPSec Phase 1 started (Initiated by me).

26/06/14 09:12:16,904 racoon[19779]: IKE Packet: transmit success. (Initiator, Aggressive-Mode message 1).

26/06/14 09:12:16,905 racoon[19779]: >>>>> phase change status = Phase 1 started by us

26/06/14 09:12:16,909 configd[18]: network changed.

26/06/14 09:12:19,905 racoon[19779]: IKE Packet: transmit success. (Phase 1 Retransmit).

26/06/14 09:12:23,204 racoon[19779]: IKE Packet: transmit success. (Phase 1 Retransmit).

26/06/14 09:12:26,484 racoon[19779]: IKE Packet: transmit success. (Phase 1 Retransmit).

26/06/14 09:12:26,831 configd[18]: IPSec disconnecting from server XXX.XXX.XXX.XXX

26/06/14 09:12:26,831 racoon[19779]: IPSec disconnecting from server XXX.XXX.XXX.XXX




Kan ik me voorstellen 🙂



Dank voor deze info. De technici gaan er even op los. Ik laat het weten als ze iets ontdekken.
Uit veiligheid overwegingen plaats ik de url niet in een public forum.



Ik gebruik shrew (https://www.shrew.net) als VPN client.

Na inloggen laat deze de volgende informatie zien; Transport: NAT-T RFC / IKE | ESP

IKE Fragmentation disabled.



Shrew documentatie staat online: https://www.shrew.net/static/help-2.1.x/vpnhelp.htm




Om wat gerichter te kunnen onderzoeken wat er aan de hand is hebben de technici wat meer info nodig. Kan je ons helpen op een antwoord op onderstaande 2 vragen?



- Naar welke omgeving wordt een VPN sessie wordt opgebouwd (IP range, SaaS dienst)

- Welk protocol wordt gebruikt



Of heb je een beschrijving van hoe je je aanmeldt op je netwerk? Via welke url gaat dit? We horen het graag!

Reageer