Windows Server 2025: crash VPN RRAS (ipnathlp.dll 0xc0000005) – fix KB5046617

Su Windows Server Datacenter 2025 l’abilitazione della VPN in RRAS può provocare crash immediati di “Routing and Remote Access” e del “Remote Access Connection Manager”, con eccezione 0xc0000005 in ipnathlp.dll. In questa guida trovi diagnosi, fix con KB5046617, workaround sul NAT e checklist di verifica.

Indice

Sintomi e contesto

Su una nuova installazione di Windows Server Datacenter 2025, la semplice configurazione di RRAS per fornire servizi VPN (SSTP/L2TP/IKEv2) conduce allo spegnimento improvviso dei componenti di accesso remoto. Il comportamento tipico è il seguente:

Il servizio Routing and Remote Access (RemoteAccess) va in crash durante o subito dopo l’attivazione della configurazione VPN.
Il servizio Remote Access Connection Manager (RasMan) si arresta perché dipendente da RemoteAccess oppure a causa di errori di inizializzazione dello stack RAS.
Nel Visualizzatore eventi compaiono errori applicativi e del Service Control Manager.

Eventi tipici in Event Viewer

Log: Application
Event ID: 1000 (Application Error)
Faulting application name: svchost.exe_RemoteAccess
Faulting module name: ipnathlp.dll
Exception code: 0xc0000005 (Access Violation)

Log: System
Event ID: 7034 (Service Control Manager)
The Routing and Remote Access service terminated unexpectedly. </code></pre>

<p>La stessa configurazione, replicata su Windows Server Datacenter 2022, non genera errori: i servizi restano in stato <em>Running</em> e i client VPN si collegano regolarmente. Questo elemento comparativo è utile per scartare problemi di rete o di configurazione di base.</p>

<h2>Causa tecnica</h2>
<p>Il crash è riconducibile a un bug nelle prime build di Windows Server Datacenter 2025 all’interno del componente <code>ipnathlp.dll</code> (helper NAT legacy di RRAS). L’<em>access violation</em> (0xc0000005) si manifesta quando il servizio RemoteAccess carica la libreria per gestire il NAT IPv4: è sufficiente che il ruolo RRAS sia configurato con NAT abilitato, anche senza traffico significativo. Il problema non dipende dal protocollo VPN (SSTP, L2TP/IPsec, IKEv2): la condizione scatenante è il percorso codice del NAT in RRAS.</p>

<h2>Soluzione raccomandata</h2>
<p>Microsoft ha corretto il difetto nelle <strong>cumulative update</strong> successive: l’aggiornamento <strong>KB5046617 (12 novembre 2024)</strong> — e qualunque CU più recente — sostituisce <code>ipnathlp.dll</code> con una versione che non genera più l’<em>access violation</em>. Installare la CU e riavviare il server elimina il crash in modo definitivo.</p>

<h2>Piano di intervento sintetico</h2>
<table>
  <thead>
    <tr>
      <th>Passo</th>
      <th>Intervento</th>
      <th>Perché funziona</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Riconoscere il problema</td>
      <td>Il difetto è noto per le prime build di Windows Server Datacenter 2025: <code>ipnathlp.dll</code> contiene un bug che manda in crash RRAS.</td>
      <td>Confermato da segnalazioni Microsoft.</td>
    </tr>
    <tr>
      <td>Applicare la patch ufficiale</td>
      <td>Installare l’aggiornamento cumulativo <strong>KB5046617 (12&nbsp;nov&nbsp;2024)</strong> o un CU successivo.</td>
      <td>La nuova versione di <code>ipnathlp.dll</code> corregge l’access‑violation.</td>
    </tr>
    <tr>
      <td>Work‑around temporaneo</td>
      <td>Finché non puoi aggiornare, disattiva il <strong>NAT</strong> in RRAS.</td>
      <td>Il bug si manifesta solo quando il NAT è abilitato.</td>
    </tr>
    <tr>
      <td>Verifica post‑patch</td>
      <td>Dopo l’update riavvia e controlla che i servizi siano <em>Running</em> e che non compaiano nuovi Event ID 1000/7034.</td>
      <td>Conferma che il problema è risolto.</td>
    </tr>
    <tr>
      <td>Ulteriore diagnosi</td>
      <td><code>sfc /scannow</code>, <code>DISM /RestoreHealth</code>, monitoraggio con ProcMon o ticket Microsoft con memory‑dump.</td>
      <td>Esclude file corrotti o driver di terze parti.</td>
    </tr>
  </tbody>
</table>

<h2>Procedura dettagliata</h2>

<h3>Verifica preliminare della build e degli aggiornamenti</h3>
<p>Prima di intervenire, annota versione e stato patch del server. Questi comandi aiutano a documentare la baseline.</p>
<pre><code>PowerShell
Versione e build del sistema
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
  Select-Object ProductName, ReleaseId, CurrentBuild, CurrentBuildNumber, DisplayVersion

Hotfix installati (cerca la CU di novembre 2024 o successive)

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20 HotFixID, InstalledOn

Stato servizi RRAS/RasMan

Get-Service RemoteAccess, RasMan | Select-Object Name, Status, StartType </code></pre>

<h3>Installazione dell’aggiornamento cumulativo</h3>
<p>Hai tre strade tipiche; scegli quella che si adatta al tuo processo di patching.</p>
<ol>
  <li><strong>Windows Update / WSUS</strong>: approva e distribuisci l’ultima CU disponibile per Windows Server 2025. Al termine, <em>riavvio obbligatorio</em>.</li>
  <li><strong>Pacchetto offline (.msu)</strong>: se operi in ambienti isolati, usa <code>wusa</code>.
    <pre><code>wusa.exe &lt;Percorso&gt;\KB5046617-x64.msu /quiet /norestart
shutdown /r /t 0
</code></pre>
  </li>
  <li><strong>DISM</strong> (immagini montate o riparazioni): utile in scenari avanzati.
    <pre><code>DISM /Online /Add-Package /PackagePath:&lt;Percorso&gt;\KB5046617-x64.msu

Dopo il riavvio, verifica che la CU sia presente in Programmi e funzionalità > Aggiornamenti installati o tramite Get-HotFix.

Work‑around: disabilitare NAT in RRAS (se non puoi patchare subito)

Se la finestra di manutenzione non è immediatamente disponibile, il modo più rapido per stabilizzare il ruolo è disattivare il NAT di RRAS. Tieni presente che, se usi il server come gateway NAT per la LAN, questa scelta interromperà il traffico di traduzione: valuta l’impatto.

Da interfaccia grafica

Apri Routing and Remote Access (rrasmgmt.msc).
Click destro sul nome del server > Disabilita Routing and Remote Access (per applicare modifiche in sicurezza).
Riabilita il ruolo > Configura e abilita Routing and Remote Access e scegli un profilo che non includa NAT.
Nella struttura, espandi IPv4 > NAT e rimuovi eventuali interfacce contrassegnate come Pubbliche con traduzione attivata.

Da riga di comando

Le installazioni che hanno ereditato configurazioni legacy possono ancora gestire il NAT di RRAS con netsh. Esempi:

net stop remoteaccess

:: Elenca le interfacce NAT configurate
netsh routing ip nat show interface

:: Disattiva la traduzione per una specifica interfaccia (sostituisci "WAN" con il nome reale)
netsh routing ip nat delete interface name="WAN"

:: In alternativa, rimuovi completamente la componente NAT
netsh routing ip nat uninstall

net start remoteaccess

Nota: questi comandi impattano solo il NAT legacy di RRAS. Non modificano eventuali NAT creati con New-NetNat (stack NAT del networking moderno) o soluzioni SDN/Hyper‑V.

Verifica post‑patch e test di non regressione

Dopo l’installazione della CU e il riavvio, esegui la seguente checklist.

I servizi RemoteAccess e RasMan sono in stato Running e con StartType desiderato (Automatico/Automatico ritardato).
Non vengono generati nuovi Event ID 1000 (Application Error) su svchost.exe_RemoteAccess o ipnathlp.dll.
Non compaiono Event ID 7034/7031 (terminazioni inaspettate/riavvii dei servizi).
I client VPN riescono a stabilire e mantenere la sessione (autenticazione, assegnazione indirizzo, routing).
Le regole di firewall e i criteri NPS (se presenti) risultano invariati.

Comandi utili per l’audit rapido:

PowerShell
Stato servizi
Get-Service RemoteAccess, RasMan

Eventi recenti per RemoteAccess (ultime 24h)

Get-WinEvent -FilterHashtable @{
LogName = 'Application';
StartTime = (Get-Date).AddDays(-1);
ID = 1000
} | Where-Object {$.Message -match 'svchost.exeRemoteAccess|ipnathlp.dll'} |
Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message

Get-WinEvent -FilterHashtable @{
LogName = 'System';
StartTime = (Get-Date).AddDays(-1);
ID = 7031,7034
} | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message

Diagnostica avanzata (se il problema persiste)

Se dopo la patch noti ancora instabilità, affronta i seguenti punti per escludere interferenze locali.

Integrità dei componenti

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

RISULTATO atteso: nessuna corruzione rilevata; eventuali riparazioni completate. Se SFC sostituisce file di sistema, riavvia e ripeti la verifica.

Conflitti di terze parti

Driver NDIS, filtri WFP, agent di sicurezza con ispezione del traffico (VPN client, IDS/IPS) possono agganciarsi allo stack di rete: prova un avvio in modalità provvisoria con rete o rimuovi temporaneamente i filtri.
Controlla gli upper/lower filters nelle classi di rete in registro se hai installazioni di vecchi driver.

Raccolta di dump locali

Se vuoi aprire un ticket con Microsoft, abilita i dump processo su crash per svchost.exe che ospita RemoteAccess:

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\svchost.exe" /v DumpType /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\svchost.exe" /v DumpCount /t REG_DWORD /d 10 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\svchost.exe" /v DumpFolder /t REGEXPANDSZ /d "C:\Dumps" /f
mkdir C:\Dumps

Alla successiva eccezione, troverai il memory dump in C:\Dumps. Ricorda di rimuovere la configurazione quando hai finito per evitare occupazione disco.

Tracciamento con ProcMon

Un filtro minimo per diagnosticare l’accesso a ipnathlp.dll durante l’inizializzazione:

Process Name: svchost.exe is svchost.exe
Command Line contains: -k NetworkService -p -s RemoteAccess (o analogo gruppo servizi)
Operation: Load Image, CreateFile, RegOpenKey
Path contains: ipnathlp.dll

Osserva il punto esatto in cui il processo termina: gli ultimi eventi spesso chiariscono se l’eccezione è correlata a un file, a una chiave di registro o a una libreria ausiliaria.

Implicazioni architetturali

Il difetto colpisce il NAT helper integrato nel RRAS “classico”. Non coinvolge il NAT di New-NetNat (stack moderno del networking) né funzionalità SDN di datacenter. Tuttavia, molte implementazioni di VPN su RRAS si appoggiano al NAT per semplificare l’uscita Internet dei client remoti o per isolare segmenti. Se il tuo design dipende fortemente dal NAT su RRAS, valuta temporaneamente:

spostare la traduzione su un appliance esterno (firewall o router fisico/virtuale);
usare il server solo come terminazione VPN fino al completamento del patching;
in ambienti Azure/VMware, impiegare NVA o NAT gateway dedicati per evitare il percorso codice di RRAS.

Confronto con Windows Server 2022

La funzionalità RRAS su Windows Server 2022 non presenta il crash descritto. Questo dato è prezioso per circoscrivere la regressione alle prime release del ramo 2025 e giustifica l’urgenza di adottare la CU correttiva su sistemi 2025 già messi in produzione.

Checklist operativa pronta all’uso

Congela cambi su RRAS finché il patching non è completato.
Raccogli build e hotfix (Get-HotFix).
Pianifica finestra con riavvio.
Installa KB5046617 o CU successiva.
Riavvia e verifica servizi ed eventi.
Testa un set di connessioni VPN (autenticazione, throughput, accesso alle risorse interne).
Rimuovi eventuale workaround di disabilitazione NAT, se lo avevi applicato.
Monitora per 24–48 ore i log Applicazione/Sistema e le metriche di affidabilità.

Domande frequenti

Quali protocolli VPN sono interessati?

Il problema è legato al componente NAT di RRAS, non al protocollo VPN. Di conseguenza, SSTP, L2TP/IPsec e IKEv2 possono tutti manifestare il crash se il NAT legacy è attivo. Se il server opera solo come terminazione VPN senza NAT, la probabilità di incontrare l’eccezione si riduce drasticamente.

Posso usare il NAT moderno (`New-NetNat`) come alternativa?

Il NAT di Windows implementato via New-NetNat non è lo stesso percorso codice del NAT legacy di RRAS. In alcuni scenari può sostituire temporaneamente la traduzione, ma richiede progettazione attenta delle rotte e dei profili firewall. Testa accuratamente prima di adottarlo in produzione.

Se non posso riavviare subito, come preservo l’accesso remoto?

Disabilita il NAT di RRAS e fornisci il traffico Internet ai client remote via proxy o rotte dedicate attraverso un gateway esterno. Mantieni la VPN per l’accesso alle risorse interne, rinunciando temporaneamente alla “full tunnel” con uscita Internet locale.

Devo modificare i criteri NPS o i certificati?

No. Il fix riguarda una libreria di sistema; criteri di autenticazione, certificati e profili di cifratura restano invariati. Tuttavia, dopo il riavvio verifica comunque l’associazione del certificato SSTP e la disponibilità CRL/OCSP.

Come capisco se la patch è effettivamente in vigore?

Oltre a Get-HotFix, puoi controllare la data/numero di versione di ipnathlp.dll nelle proprietà del file in %windir%\System32. Dopo la CU correttiva, il file risulta aggiornato e non si ripresentano gli Event ID 1000 correlati.

Esempio di playbook di migrazione/rollback

Per ambienti a disponibilità elevata, usa un approccio a “scaglioni”:

Replica la topologia in un ambiente di pre‑produzione con snapshot.
Applica la CU e simula i flussi VPN/NAT critici.
Pilota: aggiorna un numero limitato di server periferici.
Estendi l’aggiornamento all’intero parco.
Rollback (solo se indispensabile): disinstalla la CU e ripristina lo snapshot; non consigliato se l’aggiornamento risolve il crash.

Template di comunicazione agli stakeholder

Se il server eroga VPN a utenti finali, comunica in anticipo la finestra di manutenzione:

Oggetto: Manutenzione straordinaria VPN — Windows Server 2025
Quando: <data/ora locale> — Durata stimata <N minuti>
Impatto: possibili interruzioni della connessione VPN
Motivo: installazione aggiornamento cumulativo per stabilità RRAS
Azione utente: in caso di disconnessione, riprovare dopo <N> minuti

Integrazione con la sicurezza

L’adozione tempestiva della CU non è solo una misura di stabilità: riduce la superficie di rischio. Crash ripetuti su servizi di rete possono generare condizioni di denial‑of‑service involontarie o aprire finestre a stati incoerenti dello stack. Inserisci il patching RRAS nei tuoi KPIs di hardening e convalida periodicamente:

policy TLS e suite di cifratura ammessa per SSTP/IKEv2;
scadenze certificati, lunghezza chiavi, algoritmi (RSA/ECDSA);
filtri firewall in ingresso su porte VPN;
monitoraggio WAF/VPN e alert su errori 691/809/812 lato client.

Riepilogo

Il crash dei servizi VPN su Windows Server Datacenter 2025 è causato da un difetto in ipnathlp.dll presente nelle prime release. L’installazione della KB5046617 (12 novembre 2024) — o di qualsiasi cumulativo successivo — aggiorna la libreria e elimina l’eccezione 0xc0000005. Se non puoi patchare subito, disattiva il NAT di RRAS per stabilizzare il server nell’attesa. Dopo l’aggiornamento, verifica Event Viewer, stato dei servizi e connettività end‑to‑end: a quel punto RRAS e Remote Access Connection Manager tornano a comportarsi correttamente, in linea con l’esperienza su Windows Server 2022.

Appendice: comandi e riferimenti rapidi

Attività	Comando / Azione	Note
Verificare hotfix	`Get-HotFix \| ? HotFixID -match "KB5046617"`	Mostra se la CU correttiva è presente.
Installare CU offline	`wusa KB5046617-x64.msu /quiet /norestart`	Richiede riavvio per rendere effettivo il fix.
Stato servizi RAS	`Get-Service RemoteAccess, RasMan`	Attesi: Running dopo il patching.
Eventi di crash	`Get-WinEvent` con ID 1000/7034	Assenza di nuovi eventi = risoluzione confermata.
Disattivare NAT RRAS	`netsh routing ip nat delete interface name="WAN"`	Work‑around temporaneo fino al patching.

In sintesi

Il crash deriva da un bug in ipnathlp.dll introdotto nelle prime release di Windows Server Datacenter 2025. L’aggiornamento cumulativo KB5046617 (e tutti i CU successivi) lo risolve; in attesa della patch, disabilitare NAT in RRAS riduce gli arresti anomali. Dopo l’aggiornamento, RRAS e Remote Access Connection Manager tornano a funzionare correttamente, analogamente a Windows Server 2022.

Se gestisci parchi server ampi o infrastrutture regolamentate, incorpora questo fix nel tuo ciclo di patching standard, prevedi test di regressione e monitora i log di stabilità nei giorni successivi all’aggiornamento.