Vraag

IPSec in het buitenland

  • 8 oktober 2018
  • 64 reacties
  • 1221 keer bekeken

Sinds enige tijd overgestapt op KPN 4G en eigenlijk zeer tevreden maar ik loop tegen het issue aan dat IPSec geblokkeerd wordt door KPN wat betekent dat ik geen VPN op kan zetten naar de zaak. In Nederland kreeg ik dit opgelost door advancedinternet te kiezen als APN (zie https://forum.kpn.com/mobiele-diensten-18/ipsec-441328 voor de pagina waar ik deze oplossing vond) maar ik zit nu in Duitsland en verbinden lukt niet! Als ik tether via Tele2 zit ik er direct op. Ik heb dan ook 2 vragen:
- hoe kan ik e.e.a. ook in het buitenland gebruiken?
- waarom blokkeert KPN IPSec?

64 reacties

Reputatie 7
Badge +30
Hmm, daar ging mijn idee 😃 Ik heb eigenlijk net niet genoeg ervaring om de hele log van Pluto te begrijpen, maar ik neig echt heel erg naar een probleem met hoe de VPN werkt en hoe NAT werkt bij KPN.

OF, deelt de VPN server een IP uit in dezelfde range als de KPN NAT range? Maar heeft Tele2/T-Mobile/Vodafone een andere NAT range die niet overeenkomt met de VPN IP Range? En dat hierdoor de routing table op de telefoon in de war komt.

Maar Marcia, dit "probleem" is misschien wel een algemeen probleem met denk ik een bepaald type VPN (range) icm de standaard APN toch?
  • https://forum.kpn.com/mobiele-diensten-18/ipsec-441328
Reputatie 7
Badge +30
Ik heb eigenlijk geen idee of dit überhaupt kan op een iPhone.
Deze misschien? https://itunes.apple.com/us/app/lirum-device-info-lite/id591660734?mt=8

Ik heb op dit moment geen test sim om dit te proberen, maar volgensmij deelt portalmmm/internet gewoon 10.0.0.0/8 IPs uit (waarschijnlijk is die 10/8 verder gesubnet).
Vodafone levert ook een IP in de 10/8 range: 10.121.205.28 bijvoorbeeld maar met een subnetgrootte van /29. Kans is dus kleiner dat het e.e.a. overlapt.
Geen idee hoe Tele2 dit doet, en wat de subnetmaskers zijn bij zowel Vodafone als KPN, en welke range je VPN connectie gebruikt.

@Marcia_, weet jij dit toevallig of kan je dit na vragen? Hoe groot zijn ze subnetten die voor KPN 4g gebruikt worden? Zijn dat "gewoon" /24'jes of a la Vodafone /29'jes?

Robin
Reputatie 7
Badge +30
Zou t dan toch een /32 zijn zoals die app zegt met een statische route ofzo?

@Marcia_?
Reputatie 7
Badge +28
Ik heb zelf geen antwoord op de vragen over submetten. Heb het wel bij een collega van de technische dienst nagevraagd, maar die wist het ook niet direct. Wel is dat uit te zoeken, dus als we contact opnemen met jou, Tom, is dat iets om na te vragen bij mijn collega. Dan kunnen we het door middel van het lopende ticket verder uit laten zoeken.

Voor wat betreft de compensatie, hier kom ik later vandaag op terug.
Reputatie 7
Badge +28
Ik heb zelf maar weer even gebeld met onze technische dienst en de collega heeft weer doorgegeven dat je een update wenst. Vooralsnog dus geen duidelijkheid van mijn kant, sorry. Ook over compensatie wil ik dus nog niets roepen, omdat mij nog steeds niet duidelijk is wat er precies speelt. Je hebt dus niet zoveel aan deze update, maar ik wilde je het wel even laten weten.
Reputatie 7
Badge +28
Begrijpelijk! Heeft mijn collega alleen maar laten weten dat het onderzoek nog bezig is of daarbij ook inhoudelijke informatie gegeven? Niet dat het veel uitmaakt, maar ik ben wel benieuwd waarom het zo lang duurt. Hopelijk wordt je klacht snel en naar wens opgelost. Mocht ik nog iets kunnen doen, laat je het me dan weten?
Reputatie 7
Badge +28
Ik dacht dat het allang opgelost zou zijn 😞.. Ik bel er zelf morgen ook even voor je achteraan!
Reputatie 7
Badge +30
Zit je bij Tele2 ook op het Vodafone.de netwerk?
Reputatie 7
Badge +30
Maar, eigenlijk snap ik de hele gang van zaken niet. Volgensmij is dit gewoon een probleem met hoe de APN NAT doet, en wanneer je advancedinternet gebruikt is dit niet aan de orde. Echter, die werkt niet in het buitenland.

Ik verwacht van een Technische Dienst van een grote provider dat zij of bekend zijn met dit probleem (er zullen vast meer klanten zijn die een IPSec VPN opzetten op basis van XAUTH).
En, eigenlijk snap ik niet zo goed wat de aansluiting van TS hiermee te maken heeft, volgensmij kan de Technische Dienst dit heel goed zelf testen. Eén van hen zal vast wel een IPSec servertje hebben en anders kunnen ze die vast wel even maken en dit testen. Dan kunnen ze ook nog hun eigen Linux client gebruiken en hebben ze zelf direct toegang tot de logs van beide kanten van de IPSec tunnel.

Ik heb toegang tot deze logs. En ik heb zelf geen KPN mobiel aansluiting bij de hand om dit te testen, maar volgensmij (na het zien van de logregel die TS plaatste) heeft dit te maken met hoe NAT gedaan wordt op de portalmmm APN, en wordt het eerste bericht van de IPSec verbinding met een ander extern IP gedaan dan daarna. En dan is de VPN server in de war (logisch).

Ik weet niet in hoe verre TS en zijn/haar werkgever hier tijd in willen steken, maar met iets meer log regels of een simpele TCPdump/pcap zou al bevestigd kunnen worden of het inderdaad om meerdere (externe) IPs gaat.

Robin
Zit je bij Tele2 ook op het Vodafone.de netwerk?
Nee, die zit op Telekom de maar dat netwerk geeft exact hetzelfde resultaat.... tweede screenshot is via de Tele2 tether. (Direct verbinding dus...)
Beste KPN,

Uw Webcare collega’s gaven aan mij niet te kunnen helpen en dat ik op het forum assistentie kon verwachten. Inmiddels een dag verder maar ik zie nog geen reactie. Wanneer mag ik een oplossing verwachten voor dit idiote probleem?
Inmiddels in Slovenië en uiteraard...hetzelfde issue. Tetheren via Tele2 op MOBITEL werkt, rechtstreeks via mijn KPN SIM wederom niet 😞

Update; kwam hier een Nederlander tegen met Vodafone NL via wiens verbinding ik ook even mocht testen en ook dan werkt het helemaal. Heb ik een fout gemaakt door naar KPN te verhuizen?
3 dagen later, geen reactie. Ik word er oprecht bedroefd van ?
Beste Tom, welkom! Jammer om te lezen dat je hier tegenaan loopt. Zoals je gemerkt hebt, is het wat drukker op het forum, dus we komen nu pas aan je vraag toe. Excuses hiervoor!

Zou je in je forumprofiel je mobiele nummer en evt. postcode + huisnummer willen zetten? Dan kan ik onze technische dienst eens bellen om te kijken of zij een antwoord op je vraag hebben.

Dank voor je reactie!
Ik heb e.e.a. Toegevoegd. Ik wil benadrukken dat ik binnen Nederland hier dus ook al tegen aanliep en pas na aanpassen naar APN advancedinternet überhaupt gebruik kon maken van IPSEC VPN op mijn telefoon.
Ik vraag me eerlijk gezegd ook af of het niet tegen de netneutraliteit is voor KPN om dergelijke verbindingen te blokkeren en wil dus niet alleen een oplossing maar ook een motivatie van deze in mijn ogen bizarre blokkade .
Hartelijk dank! Ik heb met onze technische dienst gebeld en het is niet helemaal duidelijk hoe nu de vork in de steel zit. Daarom wordt het door middel van een ticket uitgezocht en er wordt binnen 5 werkdagen contact met je opgenomen. Wil je nog even laten weten wat daaruit gekomen is? Dan weet ik (en eventueel anderen die hier tegenaan lopen) het ook!
Niet helemaal het antwoord waar ik op hoopte, maar goed. Hoe word ik gecontacteerd?
Hi Marcia_

Inmiddels de logs doorgestuurd gekregen. (Alleen!) via de KPN verbinding verschijnt onderstaande message 4x in de VPN Concentrator na Sending XAUTH message:
packet from 89.200.77.131:500: Main Mode message is part of an unknown exchange

Bij verbinding maken via een andere provider (of WiFi) verschijnt dit bericht dus niet maar:
parsing XAUTH reply
Inmiddels speelt het probleem ruim een week en zijn we gearriveerd in Kroatië en ook hier geen VPN via KPN (en wel via Tele2 NL en lokale WiFi 😥 )

Ook nog niets van de technische dienst vernomen helaas.
Ha Tom, ik verwacht inderdaad dat het bij jou in geen enkel land werkt, behalve dan in Nederland. Geef mijn collega's nog heel even, de vijf werkdagen zijn nog niet voorbij. Ben je nog wel even in het buitenland of kom je binnen deze termijn weer in Nederland?
Daar lijkt het inderdaad sterk op ;)
Ik ben nog langer in het buitenland dus testen zal geen probleem zijn 😁
Hebben je collegas mijn Posts wel gezien? (Specifiek de melding uit de VPN log)
Ik heb de meldingen doorgestuurd naar onze technische dienst, zodat zij dit bij het ticket in kunnen laten zetten! :-)
Super, dank je.
Heb je inmiddels iets vernomen van mijn collega's? Ik ben benieuwd wat er uit gekomen is!
Helaas nog helemaal niks vernomen 😥
Wacht het morgen even af. Ik ben er zelf na het weekend pas weer, mocht je niets gehoord hebben, ga ik er dan opnieuw voor je achteraan. Vooralsnog ga ik er vanuit dat je vandaag of morgen wat hoort van mijn collega's.
Hoi Marcia,

Tot mijn chagrijn helaas helemaal niets van je collega's gehoord 😩
Ik hoop dat je nog wat voor me kan betekenen. Steeds reisgenoten lastig vallen als ik in moet loggen op de zaak begint wat de keel uit te hangen 😉
Jammer om dit te lezen! Goed dat je het laat weten. Ik heb opnieuw de technische dienst gebeld en mijn collega liet weten dat ze er nog mee bezig zijn. Ik heb gevraagd je een tussentijdse update te geven, dus ik ga er vanuit dat je een dezer dagen wat hoort. Excuses voor het ongemak!
Ik vind jullie prestatie in deze wel echt beneden alle peil eerlijk gezegd. 2 weken geleden het probleem gemeld en geen enkel zicht op een oplossing. Dit is niet wat ik van KPN als duurste provider van Nederland (!) verwacht 😠
Het duurt inderdaad wel lang, dat ben ik met je eens 😞. Ik weet niet precies wat er aan de hand is, dat zal mijn collega je kunnen vertellen wanneer deze contact met je opneemt. Wat ik begrepen heb, is dat er nog iets ondernomen moest worden. Dus ik vraag je toch nog even geduld te hebben.
Zojuist gebeld door een KPN engineer; er is een trace gestart. Hopelijk een oplossing voor we weer in Nederland zijn.
Maar, eigenlijk snap ik de hele gang van zaken niet. Volgensmij is dit gewoon een probleem met hoe de APN NAT doet, en wanneer je advancedinternet gebruikt is dit niet aan de orde. Echter, die werkt niet in het buitenland.

Ik verwacht van een Technische Dienst van een grote provider dat zij of bekend zijn met dit probleem (er zullen vast meer klanten zijn die een IPSec VPN opzetten op basis van XAUTH).
En, eigenlijk snap ik niet zo goed wat de aansluiting van TS hiermee te maken heeft, volgensmij kan de Technische Dienst dit heel goed zelf testen. Eén van hen zal vast wel een IPSec servertje hebben en anders kunnen ze die vast wel even maken en dit testen. Dan kunnen ze ook nog hun eigen Linux client gebruiken en hebben ze zelf direct toegang tot de logs van beide kanten van de IPSec tunnel.

Ik heb toegang tot deze logs. En ik heb zelf geen KPN mobiel aansluiting bij de hand om dit te testen, maar volgensmij (na het zien van de logregel die TS plaatste) heeft dit te maken met hoe NAT gedaan wordt op de portalmmm APN, en wordt het eerste bericht van de IPSec verbinding met een ander extern IP gedaan dan daarna. En dan is de VPN server in de war (logisch).

Ik weet niet in hoe verre TS en zijn/haar werkgever hier tijd in willen steken, maar met iets meer log regels of een simpele TCPdump/pcap zou al bevestigd kunnen worden of het inderdaad om meerdere (externe) IPs gaat.

Robin

Dank voor je reactie! Ik ben het echt volledig met je eens en had niet alleen gehoopt maar zelfs verwacht dat KPN niet alleen die conclusie zou trekken maar het ook vrij simpel zou kunnen fixen. Na ruim 2,5 week (en nog 3 dagen buitenland te gaan...) is mijn vertrouwen behoorlijk gezakt.

De logs laten wel degelijk steeds hetzelfde IP Adres zien, dat is het dus niet. Zoals je in onderstaande (enigszins geanonimiseerd mbv {XXX}) logs kunt zien:

2018:10:25-18:18:09 kerberos pluto[14729]: packet from 77.62.131.115:500: received Vendor ID payload [RFC 3947]
[…]
2018:10:25-18:18:09 kerberos pluto[14729]: packet from 77.62.131.115:500: received Vendor ID payload [xauth]
[…]
2018:10:25-18:18:09 kerberos pluto[14729]: packet from 77.62.131.115:500: received Vendor ID payload [Dead Peer Detection]
2018:10:25-18:18:09 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[5] 77.62.131.115 #12: responding to Main Mode from unknown peer 77.62.131.115
2018:10:25-18:18:09 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[5] 77.62.131.115 #12: NAT-Traversal: Result using RFC 3947: no NAT detected
2018:10:25-18:18:09 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[5] 77.62.131.115 #12: ignoring informational payload, type IPSEC_INITIAL_CONTACT
2018:10:25-18:18:09 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[5] 77.62.131.115 #12: Peer ID is ID_DER_ASN1_DN: 'C=nl, L={XXX}, O={XXX}, CN={XXX}, E={XXX}@{XXX}'
2018:10:25-18:18:09 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[5] 77.62.131.115 #12: crl not found
2018:10:25-18:18:09 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[5] 77.62.131.115 #12: certificate status unknown
2018:10:25-18:18:09 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[5] 77.62.131.115 #12: we have a cert and are sending it
2018:10:25-18:18:09 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[5] 77.62.131.115 #12: Dead Peer Detection (RFC 3706) enabled
2018:10:25-18:18:09 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[5] 77.62.131.115 #12: sent MR3, ISAKMP SA established
2018:10:25-18:18:09 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[5] 77.62.131.115 #12: sending XAUTH request
2018:10:25-18:18:13 kerberos pluto[14729]: packet from 77.62.131.115:500: Main Mode message is part of an unknown exchange
2018:10:25-18:18:16 kerberos pluto[14729]: packet from 77.62.131.115:500: Main Mode message is part of an unknown exchange
2018:10:25-18:18:19 kerberos pluto[14729]: packet from 77.62.131.115:500: Main Mode message is part of an unknown exchange
2018:10:25-18:18:32 kerberos pluto[14729]: packet from 77.62.131.115:500: Main Mode message is part of an unknown exchange
2018:10:25-18:18:40 kerberos pluto[14729]: ERROR: asynchronous network error report on ppp0 for message to 77.62.131.115 port 500, complainant 77.62.131.115: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]


Vergelijk ik dit met een verbinding via de lokale WiFi zie ik:

2018:10:25-18:17:40 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[4] 87.18.192.60:50617 #10: responding to Main Mode from unknown peer 87.18.192.60:50617
2018:10:25-18:17:40 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[4] 87.18.192.60:50617 #10: NAT-Traversal: Result using RFC 3947: peer is NATed
2018:10:25-18:17:41 kerberos pluto[14729]: | NAT-T: new mapping 87.18.192.60:50617/51932)
2018:10:25-18:17:41 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[4] 87.18.192.60:51932 #10: ignoring informational payload, type IPSEC_INITIAL_CONTACT
2018:10:25-18:17:41 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[4] 87.18.192.60:51932 #10: Peer ID is ID_DER_ASN1_DN: 'C=nl, L={XXX}, O={XXX}, CN={XXX}, E={XXX}@{XXX}'
2018:10:25-18:17:41 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[4] 87.18.192.60:51932 #10: crl not found
2018:10:25-18:17:41 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[4] 87.18.192.60:51932 #10: certificate status unknown
2018:10:25-18:17:41 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[4] 87.18.192.60:51932 #10: we have a cert and are sending it
2018:10:25-18:17:41 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[4] 87.18.192.60:51932 #10: Dead Peer Detection (RFC 3706) enabled
2018:10:25-18:17:41 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[4] 87.18.192.60:51932 #10: sent MR3, ISAKMP SA established
2018:10:25-18:17:41 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[4] 87.18.192.60:51932 #10: sending XAUTH request
2018:10:25-18:17:55 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[4] 87.18.192.60:51932 #10: parsing XAUTH reply
2018:10:25-18:17:55 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[4] 87.18.192.60:51932 #10: extended authentication was successful
2018:10:25-18:17:55 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[4] 87.18.192.60:51932 #10: sending XAUTH status
2018:10:25-18:17:56 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[4] 87.18.192.60:51932 #10: parsing XAUTH ack
2018:10:25-18:17:56 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[4] 87.18.192.60:51932 #10: received XAUTH ack, established
2018:10:25-18:17:56 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[4] 87.18.192.60:51932 #10: parsing ModeCfg request
2018:10:25-18:17:56 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[4] 87.18.192.60:51932 #10: unknown attribute type (28683)
2018:10:25-18:17:56 kerberos pluto[14729]: "D_for VPN Users to LAN-6"[4] 87.18.192.60:51932 #10: peer requested virtual IP %any
2018:10:25-18:17:56 kerberos pluto[14729]: acquired existing lease for address x.x.5.1 in pool 'VPN Pool (Cisco)'

De NAT detectie mislukt dus zodra ik via de KPN verbinding ga :(

Ik weet niet wat ze uit aan het zoeken zijn, maar dat kan Tom vast vertellen als ze weer contact hebben opgenomen met hem. Na jouw verhaal ben ik wel erg benieuwd wat er uit komt en wat de oplossing voor Tom gaat zijn.
Ik weet het ook niet, na het contact of er een trace gestart mocht worden en de vraag met welk IP adres ik een verbinding opzet is er complete radiostilte.

@Marcia_ aangezien ik mijn hele vakantie geen volledig gebruik heb kunnen maken van mijn abonnement neem ik aan dat er een (gedeeltelijke) restitutie vanuit KPN verwacht mag worden, weet jij hoe ik die procedure in gang kan zetten? (kan jij dit wellicht doen?)
Wat rot dat de communicatie vanuit ons zo slecht is, excuses daarvoor. Zo weet je niet bepaald wat je kunt verwachten, dus handig is anders. Voor wat betreft restitutie: begrijp ik goed dat je 'alleen' geen gebruik hebt kunnen maken van een VPN verbinding? Het bellen/gebeld worden en mobiel internet werkte verder wel? Dan zit er vanuit ons naar verwachting geen restitutie in: dat wat wij horen te leveren, werkt immers naar behoren.

Mede daarom ben ik benieuwd wat onze technische dienst uiteindelijk gaat zeggen. Mocht het toch zo zijn dat we echt iets nagelaten hebben, kunnen we zeker nog naar de opties kijken. Dat wil ik in ieder geval even afwachten voordat ik er een definitieve uitspraak over ga doen. Wil je het me laten weten als je maandagmiddag nog niets gehoord hebt? Dan bel ik er meteen weer achteraan.

Hopelijk heb je ondanks dit gedoe toch een aangename tijd in het buitenland!

Rot is nog heel netjes verwoord voor een probleem wat na 3 weken nog geen zicht heeft op oplossing... Ik ben onthutst door het gebrek aan voortgang, van de grootste (en duurste!) provider van Nederland had ik dit niet verwacht.

Verder; gezien het feit dat IPSEC een volstrekt normaal internet protocol betreft ben ik het niet eens met de stelling dat ik gewoon gebruik heb kunnen maken van mijn verbinding. Een voor mij essentieel protocol wordt door KPN geblokkeerd of eerder; niet goed geïmplementeerd op het voor NAT verantwoordelijke KPN apparaat en dan specifiek RFC 3947 (https://www.ietf.org/rfc/rfc3947.txt) Het feit dat collega providers in Nederland (specifiek Vodafone en prijsvechter Tele2!) dit wel correct implementeren bewijst impliciet dat er in principe ook geen technische beperking kan zijn.

Graag verneem ik hoe ik een restitutie verzoek in kan dienen.

Hmm, daar ging mijn idee 😃 Ik heb eigenlijk net niet genoeg ervaring om de hele log van Pluto te begrijpen, maar ik neig echt heel erg naar een probleem met hoe de VPN werkt en hoe NAT werkt bij KPN.

OF, deelt de VPN server een IP uit in dezelfde range als de KPN NAT range? Maar heeft Tele2/T-Mobile/Vodafone een andere NAT range die niet overeenkomt met de VPN IP Range? En dat hierdoor de routing table op de telefoon in de war komt.

[..]

Kortgezegd komt het er in mijn ogen op neer dat KPN RFC 3947 (Negotiation of NAT-Traversal in the IKE) niet correct lijkt te implementeren waardoor de VPN gateway de vervolg pakketten niet kan correleren aan de inlog van mijn device. Zie https://community.cisco.com/t5/security-documents/how-does-nat-t-work-with-ipsec/ta-p/3119442 voor meer info.

Reageer