MENU
  1. ホーム
  2. Windows Server
  3. RRAS + NPS: VPN non si connette dall’esterno (PPTP/GRE) – guida completa e soluzione L2TP/IPsec

RRAS + NPS: VPN non si connette dall’esterno (PPTP/GRE) – guida completa e soluzione L2TP/IPsec

Windows Server

La VPN di RRAS+NPS funziona in LAN ma cade dall’esterno con il messaggio “the network connection… was interrupted”? Nella maggior parte dei casi il colpevole è il GRE richiesto da PPTP bloccato/impedito dal firewall. Qui trovi diagnosi passo‑passo e la soluzione definitiva: migrare a L2TP/IPsec.

Indice

Contesto e sintomi

  • Scenario: Windows Server con Routing and Remote Access Service (RRAS) e Network Policy Server (NPS) sulla stessa macchina; VPN inizialmente configurata in PPTP.
  • Sintomi: accesso VPN riuscito dalla LAN, ma fallito da Internet con l’errore “the network connection between your computer and the VPN server was interrupted…”. L’autenticazione di per sé non è in causa, perché localmente funziona.
  • Firewall dichiarato: port‑forwarding di UDP 1812/1813/1645/1646 (RADIUS) e poi di UDP 1701/500/4500. Assente però il supporto/forward del protocollo GRE (IP proto 47), necessario a PPTP.

Analisi tecnica: perché PPTP fallisce da Internet

PPTP è un protocollo “a due piani”: usa TCP 1723 come canale di controllo per il handshake e GRE (protocollo IP 47) per il traffico dati incapsulato. Questo porta a un effetto-forbice:

  1. Il handshake TCP su 1723 va a buon fine: il client vede il server, negozia i parametri iniziali e “sembra” tutto ok.
  2. Quando il client passa ai pacchetti GRE per instaurare il tunnel dati, il firewall/NAT che non supporta GRE (o non dispone del relativo helper stateful) non sa come tradurli/inoltrarli e li blocca o li instrada male.
  3. Il client interpreta la mancata risposta GRE come interruzione della connessione e mostra l’errore.
Cliente ---Internet--- [NAT/Firewall senza GRE] --- RRAS (PPTP)
             TCP 1723  ✔  (handshake OK)
             GRE 47    ✖  (dati/tunnel non stabiliti → disconnessione)

Nel caso in esame, il firewall/gateway CentOS non offriva un’opzione “GRE passthrough” né un modulo capace di terminare/traslare GRE (PPTP helper): semplice port‑forward non basta, perché GRE non è una porta, ma un protocol number. Per NATtare correttamente GRE servono moduli di conntrack specifici (il classico “helper PPTP”); in assenza di questi, il tunnel non nasce.

Diagnostica essenziale, dal più rapido al più approfondito

Verifiche di raggiungibilità e porte

  • TCP 1723 (PPTP): verifica che il canale di controllo sia raggiungibile dall’esterno. telnet vpn.example.com 1723 Oppure (Windows): PowerShell Test-NetConnection -ComputerName vpn.example.com -Port 1723
  • UDP 500/1701/4500 (L2TP/IPsec): utili sia per test che per migrazione. sudo nmap -sU -p 500,1701,4500 vpn.example.com
  • Traceroute/MTR per individuare punti di perdita pacchetti/filtri intermedi: tracert vpn.example.com # Windows mtr -u vpn.example.com # Linux

Log di sistema utili

  • RRAS: Visualizzatore eventi → Custom Views → Server Roles → RemoteAccess. Eventi di disconnessione/timeout del tunnel (es. errori che seguono il passaggio a GRE).
  • NPS: Visualizzatore eventi → Custom Views → Server Roles → Network Policy and Access Services. Eventi di concessione/negazione (es. 6272/6273). Se in LAN l’autenticazione funziona, NPS non è la causa primaria del guasto esterno.
  • Tracciamento RRAS per diagnosi profonda: # Abilita tracing dettagliato (crea log in C:\Windows\Tracing\) netsh ras set tracing * enabled Disabilita quando hai finito netsh ras set tracing * disabled

Indicatori che puntano al problema GRE

  • Il controllo (TCP 1723) risponde ma la sessione si chiude pochi secondi dopo l’inserimento credenziali.
  • Il gateway non espone impostazioni tipo PPTP/GRE passthrough o moduli nfconntrackpptp / nfnatpptp.
  • In sniffing (Wireshark) vedi pacchetti GRE in uscita dal client e nessuna risposta dal server.

Soluzioni possibili e impatto

PropostaDettagliProContro
Abilitare GRE o mettere il server in DMZAprire il protocollo 47 o esporre temporaneamente l’host per test mirati.Mantiene PPTP senza dover riconfigurare client.Richiede supporto GRE sul firewall (helper NAT PPTP). PPTP resta debole sul piano sicurezza.
Migrare a L2TP/IPsec (soluzione adottata)Usa UDP 1701 (L2TP), UDP 500/4500 (IKE/ESP via NAT‑T). Nessun GRE.Niente requisito GRE, più sicuro di PPTP, compatibile con molti client.Richiede PSK o certificati e configurazione IPsec sul server e sui client.

Soluzione adottata: migrazione a L2TP/IPsec su RRAS

La riconfigurazione da PPTP a L2TP/IPsec ha sfruttato le porte già inoltrate (UDP 1701/500/4500). Dopo la modifica, la connessione dall’esterno ha funzionato.

Prerequisiti

  • RRAS installato e funzionante.
  • NPS sulla stessa macchina (opzionale: autenticazione locale via NPS o “Windows Authentication”).
  • Firewall/NAT con port‑forward UDP 500, 4500, 1701 verso il server RRAS. Se il server è pubblico e non dietro NAT, serve anche il protocollo ESP (IP proto 50); con NAT in mezzo, ESP viene incapsulato in UDP 4500 (NAT‑T).
  • Scelta dell’autenticazione: PSK (pre‑shared key) per avvio rapido; in produzione, preferisci certificati.

Configurazione RRAS (L2TP/IPsec)

  1. Apri Routing and Remote Access → Proprietà del server → scheda Sicurezza.
    • In Metodi di autenticazione abilita i metodi desiderati (es. EAP‑MSCHAPv2/PEAP o MS‑CHAPv2). Evita PAP in chiaro.
    • In Proprietà IPsec per L2TP, clicca Impostazioni IPsec e imposta la chiave pre‑condivisa (PSK) temporanea, oppure configura certificati (consigliato a regime).
  2. Vai su Port → Proprietà e assicurati che L2TP abbia porte abilitate (puoi disabilitare PPTP se non serve più).
  3. (Opzionale) PowerShell per impostare rapidamente la PSK: Import-Module RemoteAccess $psk = Read-Host "Inserisci PSK L2TP" -AsSecureString Set-VpnServerConfiguration -L2tpPsk $psk -PassThru

Configurazione NPS

  1. In NPS → RADIUS Clients and Servers, assicurati che il client RADIUS corrisponda all’IP con cui RRAS interroga NPS (anche se è la stessa macchina). La shared secret deve combaciare.
  2. In Policies → Network Policies, crea/modifica una policy per VPN:
    • Conditions: NAS Port Type = Virtual (VPN).
    • Constraints: EAP‑MSCHAPv2 o PEAP a seconda dei certificati disponibili; “Tunnel‑Type = L2TP” non è obbligatorio ma utile in ambienti misti.
    • Settings: imposta i profili di conformità/assegnazione IP se necessario.

Firewall/NAT su CentOS (firewalld/iptables/nftables)

Ricorda: per L2TP/IPsec dietro NAT bastano UDP 500/4500/1701 in forward verso il server RRAS.

# firewalld (esempio)
firewall-cmd --permanent --add-forward-port=port=500:proto=udp:toport=500:toaddr=192.0.2.10
firewall-cmd --permanent --add-forward-port=port=4500:proto=udp:toport=4500:toaddr=192.0.2.10
firewall-cmd --permanent --add-forward-port=port=1701:proto=udp:toport=1701:toaddr=192.0.2.10
firewall-cmd --reload

nftables (schema minimale)

nft add table inet nat
nft add chain inet nat prerouting { type nat hook prerouting priority -100 ; }
nft add rule inet nat prerouting udp dport {500,4500,1701} dnat to 192.0.2.10

iptables (legacy)

iptables -t nat -A PREROUTING -p udp --dport 500  -j DNAT --to 192.0.2.10
iptables -t nat -A PREROUTING -p udp --dport 4500 -j DNAT --to 192.0.2.10
iptables -t nat -A PREROUTING -p udp --dport 1701 -j DNAT --to 192.0.2.10

Client Windows: configurazione L2TP/IPsec

  1. Su client dietro NAT (quasi tutti), abilita la chiave di registro per NAT‑T: reg add HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent ^ /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 2 /f Valori: 2 = client e server dietro NAT; 1 = solo server dietro NAT; 0 = default.
  2. Crea la connessione: New-VpnConnection -Name "VPN-Azienda" -ServerAddress "vpn.example.com" ` -TunnelType L2TP -L2tpPsk "PSK-segreta" ` -AuthenticationMethod MSChapv2 -EncryptionLevel Required -RememberCredential
  3. Prova la connessione e verifica che, durante il tentativo, RRAS e NPS registrino eventi coerenti.

Risultato

Una volta commutato RRAS su L2TP/IPsec e configurato il port‑forward di UDP 500/4500/1701, la connessione VPN dall’esterno ha iniziato a funzionare regolarmente. La causa non era RRAS/NPS, ma l’assenza di supporto GRE per PPTP sul firewall.

Se vuoi restare su PPTP (non consigliato)

Puoi risolvere abilitando TCP 1723 e protocollo 47 GRE in entrata/uscita e assicurandoti che il dispositivo NAT disponga dell’helper PPTP (stateful GRE). Esempi su Linux:

# Moduli utili (se disponibili)
modprobe ip_gre
modprobe nfconntrackpptp
modprobe nfnatpptp

Consenti GRE in forward

iptables -A FORWARD -p gre -j ACCEPT

NAT per il canale di controllo PPTP (TCP 1723)

iptables -t nat -A PREROUTING -p tcp --dport 1723 -j DNAT --to 192.0.2.10
iptables -A FORWARD -p tcp -d 192.0.2.10 --dport 1723 -j ACCEPT

Abilita forwarding IP (se non già attivo)

sysctl -w net.ipv4.ip_forward=1

Verifica che il gateway supporti davvero il conntrack per PPTP; in assenza di helper, il solo “aprire GRE” non è sufficiente a NATtare correttamente il traffico.

Opzioni moderne (consigliate al posto di PPTP)

  • L2TP/IPsec: già risolutivo in questo caso. Ampio supporto client, sfrutta NAT‑T (UDP 4500), niente GRE.
  • IKEv2: veloce, stabile con mobilità (MOBIKE), usa UDP 500/4500. Ottimo con certificati e NPS/EAP.
  • SSTP: incapsulato in HTTPS TCP 443; attraversa proxy e reti restrittive. Ideale quando UDP è limitato.
  • OpenVPN: UDP/TCP su porta a scelta, forte flessibilità, ampio ecosistema.
  • WireGuard: design moderno, performance eccellenti, configurazione minimale (UDP singola porta).

Test rapidi di connettività (prontuario)

  • PPTP (TCP 1723): telnet vpn.example.com 1723 o, in PowerShell Test-NetConnection vpn.example.com -Port 1723
  • L2TP/IPsec: sudo nmap -sU -p 500,1701,4500 vpn.example.com
  • MTU path discovery (se sospetti frammentazione/PMTUD): # Windows ping vpn.example.com -f -l 1350 Linux/macOS ping -M do -s 1350 vpn.example.com

Checklist di troubleshooting

  1. WAN → Server: IP pubblico raggiungibile? DNS risolve correttamente?
  2. Port‑forward: per L2TP/IPsec, UDP 500/4500/1701 → RRAS; per PPTP, TCP 1723 + GRE 47 (con helper).
  3. RRAS: L2TP attivo? PSK/certificati impostati? PPTP disabilitato se non usato?
  4. NPS: esiste una Network Policy che consente l’accesso? Corrispondenza di condizioni e metodi EAP.
  5. Client: registro NAT‑T configurato (AssumeUDPEncapsulation…)? Credenziali e domini corretti?
  6. Log: controlla Event Viewer (RRAS/NPS) e, se serve, abilita netsh ras tracing.

Errori comuni e come evitarli

  • Aprire solo le “porte RADIUS”: non serve ai client VPN; servono le porte/tipi della VPN scelta (PPTP/L2TP/IKEv2…).
  • Dimenticare GRE con PPTP: TCP 1723 da solo non basta; senza helper, GRE non attraversa il NAT.
  • Confondere ESP con le porte: ESP è protocollo IP 50, non una porta. Con NAT usa NAT‑T (UDP 4500).
  • PSK deboli: usa chiavi robuste e ruotale; preferisci certificati in produzione.
  • Client dietro NAT rigidi: SSTP (TCP 443) è spesso la scappatoia più semplice quando l’UDP è filtrato.

Approfondimento sicurezza

PPTP è considerato obsoleto e vulnerabile (in particolare con MS‑CHAPv2). Per ambienti moderni:

  • Preferisci IKEv2 o SSTP con EAP robusti e certificati.
  • Se usi L2TP/IPsec, evita PAP/CHAP; usa EAP‑MSCHAPv2/PEAP e cura i certificati.
  • Segmenta la rete: assegna VPN in VLAN dedicate, applica ACL e limiti “least privilege”.
  • Monitora accessi con NPS, centralizza i log, abilita alert su tentativi ripetuti falliti.

Procedura riassuntiva (passo‑passo) per risolvere subito

  1. Stop al girare a vuoto: se PPTP funziona in LAN ma non da Internet, sospetta GRE.
  2. Decidi: abiliti GRE con helper NAT oppure migri a L2TP/IPsec (raccomandato).
  3. Migrazione espressa:
    • RRAS → abilita L2TP e imposta la PSK (o certificati).
    • Firewall → inoltra UDP 500/4500/1701 al server RRAS.
    • Client → abilita NAT‑T (registro) e configura L2TP con la PSK.
    • Test → verifica con nmap/Event Viewer; rivedi NPS se l’autenticazione non passa.
  4. Hardening: una volta stabile, valuta IKEv2/SSTP e migra a certificati.

Appendice: esempi di comandi utili

Verifica UDP da Windows con PowerShell

Test-NetConnection non “apre” realmente una sessione UDP come TCP, ma è sufficiente per un check di base:

# Verifica raggiungibilità IP e porta nota (TCP)
Test-NetConnection vpn.example.com -Port 1723
ICMP e route
Test-NetConnection vpn.example.com

RRAS: modifica rapida dei tipi di tunnel (script amministratore)

# Disabilita PPTP e abilita L2TP (operazioni tipicamente via GUI; qui solo esemplificative)
Apri la MMC RRAS e in "Ports" riduci PPTP a 0 porte, aumenta L2TP; poi imposta la PSK:
Import-Module RemoteAccess
$psk = Read-Host "PSK L2TP" -AsSecureString
Set-VpnServerConfiguration -L2tpPsk $psk -PassThru

NPS: controllo rapido delle policy

  • Condizioni: NAS Port Type = Virtual (VPN); utenti/gruppi autorizzati.
  • Vincoli: Authentication Methods coerenti con i client (EAP‑MSCHAPv2/PEAP).
  • Se in LAN funziona ma da Internet no, torna a concentrarti su firewall/NAT.

Conclusioni

Il caso “RRAS + NPS: impossibile collegarsi al VPN dall’esterno” con PPTP è classicamente dovuto alla mancanza di GRE sul firewall/NAT. La diagnosi si fa in pochi passi (1723 ok, GRE che non passa) e la soluzione pulita è migrare a L2TP/IPsec o, meglio, a IKEv2/SSTP in ottica sicurezza e affidabilità. Nel thread originale la migrazione a L2TP/IPsec ha risolto senza cambiare topology né introdurre nuovi appliance: è bastato configurare RRAS, adeguare il forward di UDP 500/4500/1701 e aggiornare i client. Se per vincoli devi restare su PPTP, abilita GRE con un PPTP helper stateful: solo il 1723 non basta.

Riepilogo operativo extra

Restare su PPTP

  • Aprire TCP 1723 e protocollo 47 GRE in entrata/uscita.
  • Linux/iptables: modprobe ip_gre modprobe nfconntrackpptp modprobe nfnatpptp iptables -A FORWARD -p gre -j ACCEPT iptables -t nat -A PREROUTING -p tcp --dport 1723 -j DNAT --to 192.0.2.10
  • Verifica che il dispositivo supporti stateful GRE o “PPTP helper”.

Ambiente più moderno

  • Preferisci L2TP/IPsec (già risolutivo qui) o, ancora meglio, IKEv2, SSTP, OpenVPN o WireGuard:
    • Sicurezza nettamente superiore (PPTP è obsoleto).
    • Minori problemi di attraversamento NAT/firewall (UDP 4500/500 o TCP 443 nel caso SSTP).

Test rapidi

  • telnet vpn.example.com 1723 per TCP 1723 (PPTP).
  • sudo nmap -sU -p 500,1701,4500 vpn.example.com per porte UDP L2TP/IPsec.
  • tracert/mtr per diagnosticare eventuale packet‑loss intermedio.

In sintesi: il guasto non dipendeva da RRAS/NPS, ma dall’assenza del protocollo GRE sul firewall. Passare a L2TP/IPsec, o abilitare GRE se si vuole restare su PPTP, risolve il problema.

Windows Server
Firewall L2TP/IPsec NPS PPTP RRAS Troubleshooting VPN Windows Server
Indice