L2TP/IPsec mislukt wanneer de IKEEXT-service is uitgeschakeld

Eén laptop bereikt een IKEv2-gateway maar faalt tegen een L2TP/IPsec-gateway, en de fout verschijnt voordat er een gebruikersnaam wordt verzonden. Het profiel is meestal de eerste verdachte en meestal de verkeerde. Windows voert de IPsec-sleuteluitwisseling uit in een service, en zolang die service is uitgeschakeld, heeft de ingebouwde client geen stack om mee te onderhandelen. Controleer de service voordat u één profielveld aanraakt, en zoek daarna uit wat hem heeft uitgeschakeld.

De service achter de fout

IKE and AuthIP IPsec Keying Modules, in de lijst met services weergegeven als IKEEXT, voert de sleuteluitwisseling uit en houdt op Windows de sockets UDP 500 en 4500 vast. Schakel hem uit en L2TP/IPsec en IKEv2 verliezen beide hun onderhandelaar, terwijl PPTP en SSTP blijven werken omdat ze er niet van afhangen. Die splitsing is waarom een gebruiker kan melden dat het ene VPN-type werkt en het andere op dezelfde machine dood is. De service maakt deel uit van het besturingssysteem, dus geen enkele profielinstelling kan hem vervangen.

Die twee poorten vrijmaken is het neveneffect dat slecht advies oplevert. Een tool of een forumbericht merkt dat 500 en 4500 bezet zijn, stopt de service om ze vrij te geven en verwijdert zo geruisloos IPsec van de host. De twee effecten zijn één handeling, dus elke handleiding die aanraadt de poorten vrij te maken, beschrijft een ruil in plaats van een herstelling.

Zet de service terug zonder te gissen

Stel de servicebeheerder twee vragen: wat is het opstarttype, en wat is de huidige status. De eerste vertelt of de service na een herstart terugkomt; de tweede of hij nu draait. Voer beide query's uit vanaf een verhoogde opdrachtprompt, zodat dezelfde shell daarna de instelling kan wijzigen.

sc qc ikeext
sc query ikeext

Een opstarttype Disabled verklaart het hele symptoom, en de oplossing is om het terug te zetten op Automatic en de service te starten. In de Services-console verschijnt de vermelding onder de weergavenaam IKE and AuthIP IPsec Keying Modules, dus zoeken naar IKEEXT in die lijst levert niets op. Herstart als de service pas is gestart nadat er al een mislukte verbinding had gelopen, want een stack die in die volgorde is geïnitialiseerd kan op manieren falen die er niets mee te maken lijken te hebben.

sc config ikeext start= auto
net start ikeext

Wat hem weer uitschakelt

Sommige VPN-suites van derden leveren hun eigen IPsec-implementatie en schakelen IKEEXT tijdens de installatie uit, waarna de Windows-client niet meer werkt. Het verwijderen van het andere product heeft L2TP/IPsec hersteld op machines waar profielwijzigingen niets deden, en opnieuw installeren zonder de conflicterende component eveneens. De service werd bij de installatie uitgeschakeld, niet door de gebruiker omgezet.

Groepsbeleid kan het opstarttype ook vastzetten; in dat geval wordt een lokale wijziging bij de volgende vernieuwing teruggedraaid en moet de beheerder die het beleid bezit het aanpassen. Noteer het opstarttype vóór een herstart, na een herstart en na updates van het andere product, telkens met de datum. Een waarde die steeds naar Disabled terugkeert, verraadt zijn eigenaar door het patroon, niet door giswerk.

Lees eerst de fase, dan het logboek

Als de service draait, bepaalt de fase van de fout waar u verder moet kijken. Een vastloper tijdens IKE betekent meestal dat UDP 500 of 4500 de server nooit heeft bereikt, of dat de server achter NAT zit zonder de bijpassende inkapselingsinstelling. De aanmeldingsprompt bereiken en daar falen is een PPP-authenticatieprobleem, geen IPsec-probleem. Een tunnel die opkomt en niets bereikt is een routerings- of split-tunnelfout, en alleen de eerste van die drie zit in het VPN-profiel.

Certificaatprofielen voegen een eigen fase toe. De client moet de uitgevende instantie vertrouwen en het certificaat moet de server benoemen die wordt gevalideerd; als een van beide voorwaarden faalt, meldt het dialoogvenster nog steeds een fout in de eerste onderhandeling, dus het gebeurtenissenlogboek is de plek waar de echte reden verschijnt. Lees de logregel voordat u het profiel bewerkt, want het dialoogvenster perst meerdere verschillende fouten in één zin. Een verlopen certificaat levert hetzelfde dialoogvenster op als een uitgeschakelde service, en daarom doet de logregel ertoe.

Leg voor elke poging de mislukte fase, de fouttekst en de tijdstempel vast. Die drie velden scheiden een bereikbaarheidsprobleem van een authenticatieprobleem en van een routeringsprobleem, en ze maken de volgende wijziging een beslissing in plaats van een gok.

Wat een lokale reparatie niet kan bewijzen

Het herstellen van de service verhelpt de helft van het pad dat op de laptop ligt. Een werkende service bewijst alleen de lokale helft: de verre kant moet nog steeds het gekozen voorstel, de aangeleverde inloggegevens en het bronadres waar het pakket vandaan komt accepteren. Niets wat op de laptop wordt gedaan, compenseert een firewall die UDP 500 weggooit voordat het de peer bereikt. Een geslaagde servicestatus is een voorwaarde, geen bewijs dat de tunnel tot stand komt.

IKEEXT uitschakelen om de poorten vrij te geven is alleen verdedigbaar als u aanvaardt dat Windows-IPsec-VPN's ophouden te werken. Het lost een poortconflict op door de functie te verwijderen die de poort nodig had, en dat is zelden de ruil die de gebruiker bedoelde. Bevestig voordat u iets wijzigt dat de service aanwezig is, op Automatic staat en draait, dat er geen tweede IPsec-stack is geïnstalleerd en dat de vooraf gedeelde sleutel of certificaatketen bij de gateway past.

• IKEEXT is aanwezig, staat op Automatic en draait voordat de client verbindt.
• Niets anders houdt UDP 500 of 4500 bezet.
• Er blijft geen tweede IPsec-stack van een oude client achter.
• De sleutel of certificaatketen past bij de gatewayconfiguratie.
• De mislukte fase is vastgelegd voordat het profiel werd bewerkt.