Après une installation neuve de Windows Server Datacenter 2025, certains serveurs RRAS/VPN plantent en boucle avec un code 0xC0000005 lié à ipnathlp.dll. Voici les causes, le correctif à appliquer (KB5046617) et des procédures détaillées de mise à jour, de vérification et de contournement.
Vue d’ensemble du problème
Dans un scénario de déploiement standard de serveur VPN basé sur le rôle Remote Access (RRAS), vous pouvez observer :
- Services impactés : Routing and Remote Access (
RemoteAccess) et Remote Access Connection Manager (RasMan) qui se ferment brutalement puis redémarrent en boucle. - Journaux d’événements : événements Application Error (Event ID 1000) sur
svchost.exe_RemoteAccessavec une exception0xC0000005et un module en causeipnathlp.dll. Côté System, Service Control Manager journalise des 7031/7034 (terminated unexpectedly). - Comparatif : la même configuration fonctionne sur Windows Server Datacenter 2022, ce qui oriente vers un bug spécifique à la branche 2025.
Pourquoi cela se produit
ipnathlp.dll est le composant « NAT Helper » utilisé par RRAS lorsque la fonction NAT est activée. Sur certaines builds initiales de Windows Server 2025, un défaut dans ce composant provoque un crash de l’hôte svchost.exe qui embarque le service RemoteAccess. Le phénomène est déclenché dès que RRAS initialise la pile NAT (par exemple configuration « NAT et pare-feu de base », interface publique marquée « Enable NAT on this interface », ou scénarios ICS). Tant que NAT est sollicité, le service tombe et repart en boucle.
Solution recommandée : appliquer le correctif KB5046617
Le cumulative update de novembre 2024 (KB5046617) pour Windows Server 2025 corrige ce bug dans le composant impliqué. Après application du correctif et redémarrage, RRAS démarre normalement et n’émet plus d’erreurs 0xC0000005 liées à ipnathlp.dll.
Ce que change la mise à jour
- Remplacement du binaire défectueux et stabilisation du service
RemoteAccesslorsque NAT est activé. - Passage de l’OS à un build corrigé (ligne 26100.2314 ou supérieure), inclus dans tous les LCU ultérieurs.
Chemin d’installation conseillé
- Planifier une fenêtre de maintenance et effectuer une sauvegarde système/snapshot.
- Sauvegarder la config RRAS :
netsh ras export "C:\Support\RRAS-export.txt" all - Appliquer la mise à jour :
- Via Windows Update/WSUS (recommandé).
- En offline : depuis un
.msudu catalogue, avec WUSA :wusa.exe Windows11.0-KB5046617-x64.msu /quiet /norestart - Ou avec DISM/PowerShell (utile si plusieurs packages sont requis) :
DISM /Online /Add-Package /PackagePath:"C:\Packages\Windows11.0-KB5046617-x64.msu"Add-WindowsPackage -Online -PackagePath "C:\Packages\Windows11.0-KB5046617-x64.msu"
- Redémarrer le serveur :
shutdown /r /t 0 - Vérifier (voir section suivante).
Vérifications post‑mise à jour
| Contrôle | Commande/Action | Résultat attendu |
|---|---|---|
| État du service RRAS | Get-Service RemoteAccess | Statut Running, pas d’arrêt inopiné |
| Build de l’OS | winver (Get-ComputerInfo).OsBuildNumber | Build 26100.2314 ou supérieur |
| Présence du KB | Get-HotFix -Id KB5046617 | Le correctif est listé |
| Version du binaire | (Get-Item "C:\Windows\System32\ipnathlp.dll").VersionInfo | Format-List FileVersion, ProductVersion | Version alignée au build corrigé |
| Journaux d’événements | Observateur d’événements → Application/System | Absence de nouveaux 0xC0000005 liés à ipnathlp.dll |
Contournement si la mise à jour est impossible
Si vous ne pouvez pas appliquer le KB immédiatement (ex. serveur isolé, gel de changements), dévoyez la fonction NAT hors de RRAS pour éviter l’appel au code fautif :
- Ouvrir
rrasmgmt.msc. - Clic droit sur le serveur RRAS → Configurer et activer le routage et l’accès distant.
- Choisir Configuration personnalisée puis cochez uniquement « Accès VPN ». Ne cochez ni « NAT et pare-feu de base » ni « LAN routing ».
- Dans IPv4 → NAT, supprimer toute interface marquée « Activer NAT sur cette interface ».
- Assurer la traduction d’adresses en amont : pare‑feu/routeur, appliance dédiée, ou infra existante.
Le VPN (L2TP/IPsec, IKEv2 voire PPTP si hérité) reste fonctionnel tant que le NAT est pris en charge par un équipement tiers.
Procédure complète et bonnes pratiques
Préparation et sauvegardes
- Exporter la configuration RRAS :
netsh ras export "C:\Support\RRAS-export.txt" all - Créer un point de restauration (si activé) ou un snapshot/backup d’image.
- Bloquer une fenêtre de maintenance et prévenir les utilisateurs.
Assainissement système
Exécuter une vérification d’intégrité avant/après patch pour écarter une corruption locale :
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealthVérification des pilotes et de la pile réseau
- Mettre à jour les pilotes NIC (pilotes signés, versions récentes).
- Vérifier qu’aucun filter driver tiers obsolète (VPN client, pare-feu) n’est inséré dans la pile de l’interface publique.
Validation fonctionnelle après correction
- Redémarrer RRAS :
Restart-Service RemoteAccess - Tester un tunnel VPN client (L2TP/IPsec ou IKEv2) depuis un poste externe.
- Contrôler le routage et la NAT (si RRAS gère la NAT, après patch) avec
tracertetTest-NetConnection.
Mesures de diagnostic complémentaires
Capturer un dump au moment du crash
Pour obtenir un crash dump exploitable :
md C:\Dumps
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\svchost.exe" /v DumpFolder /t REG_EXPAND_SZ /d C:\Dumps /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\svchost.exe" /v DumpType /t REG_DWORD /d 2 /fOu avec ProcDump en attente du processus :
procdump64.exe -ma -e -w svchost.exe -x C:\DumpsTracer RRAS pendant le démarrage
netsh trace start scenario=RemoteAccess capture=yes tracefile=C:\Traces\RRAS.etl
netsh trace stopExtraire les derniers événements pertinents
wevtutil qe Application /q:"*[System[Provider[@Name='Application Error'] and (EventID=1000)]]" /f:text /c:5
wevtutil qe System /q:"*[System[(EventID=7031 or EventID=7034)]]" /f:text /c:10Port mapping et prérequis réseau VPN
Si vous déplacez la NAT en amont, pensez aux ouvertures suivantes :
| Technologie | Ports/Protocoles côté serveur | Notes |
|---|---|---|
| IKEv2 | UDP 500 (IKE), UDP 4500 (NAT‑T), ESP (protocole 50) | Recommandé ; vérifier le passage d’ESP ou forcer tout‑NAT‑T (UDP 4500) |
| L2TP/IPsec | UDP 500, UDP 4500, UDP 1701 (L2TP), ESP | L2TP traverse le NAT via IPsec/NAT‑T |
| PPTP (héritage) | TCP 1723, GRE (protocole 47) | À éviter en production ; compatibilité uniquement |
Questions fréquentes
Le correctif KB5046617 est‑il déjà inclus dans les versions récentes ?
Oui. Les builds ultérieurs de Windows Server 2025 intègrent cette correction. Si votre serveur est à jour, vous êtes déjà protégé.
Y a‑t‑il un impact Active Directory ?
Non. Aucune modification de schéma ni d’API RRAS n’est requise.
Puis‑je continuer à utiliser la NAT de RRAS après correction ?
Oui. La stabilité est rétablie. Vous pouvez conserver un design « tout‑en‑un » (VPN + NAT) si vos contraintes le justifient. Dans les architectures exigeantes, la séparation des rôles (pare‑feu/routeur dédié) reste une meilleure pratique.
Comment revenir en arrière ?
Les LCU combinent souvent l’SSU. La désinstallation n’est pas toujours possible. Il est préférable d’utiliser un snapshot ou une sauvegarde d’image pour tout rollback si nécessaire.
Scripts utiles pour l’audit rapide
Vérifier l’édition, le build, la présence du KB et l’état des services :
# État de l'OS et build
Get-ComputerInfo | Select-Object OsName, OsVersion, OsBuildNumber
# Correctif installé ?
Get-HotFix -Id KB5046617 -ErrorAction SilentlyContinue
# Services RRAS
Get-Service RemoteAccess, RasMan | Format-Table -Auto
# Binaire incriminé
(Get-Item "C:\Windows\System32\ipnathlp.dll").VersionInfo |
Format-List FileVersion, ProductVersionPlan de reprise si l’incident persiste
| Étape | Action | Objectif |
|---|---|---|
| Assainir | sfc puis DISM, pilotes NIC à jour | Écarter une cause locale |
| Contourner | Désactiver la NAT RRAS, déléguer la NAT à l’amont | Stabiliser le service |
| Isoler | Reproduire sans agents/antivirus tierce partie | Éliminer les interférences de filtre réseau |
| Basculer | Temporairement migrer la terminaison VPN (OpenVPN, WireGuard, appliance) | Assurer la continuité |
| Revenir | Windows Server 2022 si contrainte forte de production | Solution conservatoire |
Points d’attention architecture
- Séparation des rôles : un pare‑feu/routeur dédié pour la NAT et un serveur RRAS pour la terminaison VPN simplifient le support.
- Journalisation : conservez
C:\Dumpset les.etlpendant quelques jours après correction pour analyse rétrospective. - Surveillance : créez une alerte sur l’Event ID 7031/7034 (SCM) et 1000 (Application Error) pour détecter tout retour du symptôme.
- Sécurité : privilégiez IKEv2/L2TP/IPsec, limitez ou retirez PPTP.
Résumé opérationnel
Le plantage de RRAS/VPN sur Windows Server 2025 est dû à un défaut de ipnathlp.dll activé par la fonction NAT. L’application du KB5046617 corrige le problème. À défaut, désactivez la NAT dans RRAS et déléguez‑la à un équipement amont. Sauvegardez la configuration, mettez à jour, redémarrez, vérifiez les journaux — votre infrastructure VPN retrouve sa stabilité.
Checklist express
- Exporter la config RRAS (
netsh ras export). - Installer KB5046617 (ou build ultérieur) puis redémarrer.
- Contrôler Services :
RemoteAccessen Running. - Vérifier l’absence d’événements 1000/7031/7034 liés à
ipnathlp.dll. - Si patch impossible : retirer la NAT de RRAS, ouvrir les ports VPN sur le pare‑feu amont.
En appliquant la mise à jour KB5046617 ou, à défaut, en désactivant temporairement NAT dans RRAS, vous devriez stabiliser votre infrastructure VPN sous Windows Server Datacenter 2025.