Vos utilisateurs VPN constatent soudainement l’absence d’Internet et l’impossibilité d’accéder aux partages internes ? Ce guide pas‑à‑pas explique comment diagnostiquer et corriger les blocages les plus courants observés sur un serveur Windows Server 2019 hébergeant RRAS (Routing & Remote Access Service).
Vue d’ensemble du problème
Les postes distants s’authentifient correctement (PPTP, L2TP /IPsec ou SSTP) : l’icône VPN passe au vert, un ping vers un serveur interne répond, mais tout le reste échoue :
- Les lecteurs réseau mappés apparaissent « hors‑ligne » et refusent de se reconnecter.
- L’icône de connectivité Windows affiche le globe gris signifiant « Accès Internet absent ».
- Aucun site Web, ni service SaaS (Sage, messagerie cloud, etc.) n’est joignable.
Dans 90 % des cas, un unique serveur fait office de contrôleur de domaine, serveur DNS et RRAS, avec une seule interface WAN sortante. Tous les clients reçoivent une adresse du pool statique attribué au serveur dans la console Accès à distance.
Architecture typique d’un déploiement RRAS
[Clients VPN]───┤Internet├───[FW]───(NIC WAN)‑[WS2019 RRAS + AD + DNS]‑(NIC LAN)───[Réseau interne]Le schéma ci‑dessus illustre un serveur « tout‑en‑un ». Le trafic entrant arrive sur l’interface WAN, est authentifié par RRAS, puis routé vers le LAN. Sans NAT explicite, le trafic sortant suit le chemin inverse ; or, si le pare‑feu périmétrique ne laisse passer que l’IP du serveur et pas celles du pool VPN, la navigation reste bloquée.
Causes probables identifiées
Tunnel complet sans traduction NAT
Par défaut, le client Windows coche « Utiliser la passerelle par défaut sur le réseau distant ». L’ensemble du flux (0.0.0.0/0) part donc dans le tunnel. Si le serveur ne réalise pas de NAT, le pare‑feu ne reconnaît pas l’adresse source (192.168.200.x par ex.) et coupe la connexion sortante.
DNS interne non transféré
Les stations pointent vers le DNS du DC. Sans redirecteurs publics, les requêtes externes expirent et le système considère la connexion comme « sans Internet ».
Routage défaillant
Une route statique héritée ou l’absence d’une passerelle par défaut valide empêche le serveur de réémettre le trafic.
Filtrage pare‑feu sortant
Les règles Windows Defender Firewall ou du firewall physique bloquent HTTP / HTTPS pour le sous‑réseau VPN.
Autorisations SMB et découverte réseau
Les partages peuvent paraître hors‑ligne si la découverte réseau est désactivée, si les identifiants sont incorrects ou si l’ordinateur ne résout pas le nom NetBIOS.
Diagnostic pas à pas
- Tester la résolution DNS
nslookup www.microsoft.com
Un « DNS request timed out » indique un problème de redirecteur. - Tracer la route externe
tracert 8.8.8.8
Si le premier saut est l’IP du pool VPN et que la requête s’interrompt, suspectez l’absence de NAT. - Inspecter les tables de routage
Sur le serveur :route print | findstr "0.0.0.0"La route par défaut doit pointer vers la passerelle du WAN. - Analyser les journaux RRAS
Observateur d’évènements → Applications and Services Logs → Microsoft / Windows / RemoteAccess. - Vérifier le pare‑feu Windows
Get-NetFirewallRule -PolicyStore ActiveStore -Direction Outbound | where {$_.Enabled -eq "True" -and $_.Action -eq "Block"}
Solutions recommandées
| Domaine | Actions concrètes |
|---|---|
| Split‑tunneling | Si la politique de sécurité de votre organisation le tolère : Côté client : décochez « Utiliser la passerelle par défaut sur le réseau distant » (Propriétés › Mise en réseau › IPv4 › Avancé). Côté serveur : ajoutez des routes statiques dans « Stratégies NPS » ou via Add-VpnConnectionRoute pour ne pousser que les préfixes internes (10.0.0.0/16, 172.16.0.0/24, etc.). Le trafic Internet sortira alors directement via la box de l’utilisateur, éliminant la problématique NAT. |
| NAT sur RRAS | Dans la console Routage et accès distant, clic droit sur le nom du serveur. Sélectionnez Configurer et activer le routage et l’accès distant. Choisissez l’option « Accès VPN et NAT ». Désignez l’interface WAN comme « Publique » avec traduction d’adresses. Tous les paquets provenant des IP du pool seront alors masqués derrière l’IP publique du serveur, satisfaisant ainsi le pare‑feu externe. |
| Redirecteurs DNS | Ouvrez dnsmgmt.msc → Propriétés du serveur → onglet Redirecteurs et ajoutez :8.8.8.8 (Google) et 1.1.1.1 (Cloudflare). Validez avec nslookup microsoft.com 8.8.8.8 pour confirmer la résolution externe. |
| Pare‑feu | Créer dans Windows Defender Firewall une règle Sortante › Autoriser › TCP 80, 443 › Profil Domaine ciblant la plage VPN (192.168.200.0/24 par ex.).Sur le firewall périmétrique, autorisez la source IP du serveur vers TCP 80/443 sortants. |
| Routage | Assurez‑vous qu’une seule route par défaut existe : route delete 0.0.0.0 mask 0.0.0.0 IF <id_vpn> route add 0.0.0.0 mask 0.0.0.0 <gateway_wan> IF <id_wan> -p |
| Partages SMB | Vérifiez que le service Computer Browser est activé ou, mieux, accédez aux partages via le FQDN (\\srv‑files.domaine.local\partage). Forcez l’authentification sur Kerberos en utilisant klist purge puis net use *. |
| Tests & journalisation | Côté client : capturez un rasphone.log en activant la journalisation via rasphone.exe › Options. Côté serveur : activez le mode débogage RRAS :netsh ras set tracing * enable |
Bonnes pratiques de sécurité et de performance
- Chiffrement fort : privilégiez SSTP ou IKEv2 avec certificats ; désactivez PPTP (MS‑CHAP v2) si possible.
- Inscription DNS automatique : configurez
ipconfig /registerdnsau logon pour garder les enregistrements A jour. - Compression WAN : activez l’option « Framing compression » dans la stratégie NPS pour améliorer les copies de fichiers.
- Limitation MTU / MSS : certains FAI imposent un MTU < 1500. Fixez le MSS à 1350 sur le firewall pour éviter la fragmentation.
- Audit : les ID 20255 et 20271 dans le journal RemoteAccess indiquent un succès ou un échec d’attribution IP ; surveillez‑les via un abonnement Event Log.
FAQ
Q : Mon serveur a déjà « Accès VPN et NAT » configuré mais la navigation reste impossible.
R : Vérifiez que l’interface sélectionnée comme « Publique » est bien celle reliée au WAN ; lors d’un changement de carte réseau, RRAS conserve parfois une référence obsolète. Supprimez puis recréez la configuration.
Q : Faut‑il ouvrir des ports supplémentaires sur le pare‑feu une fois le NAT activé ?
R : Non ; le trafic sortant est initié depuis l’intérieur, donc le FW autorise automatiquement la réponse. Seuls les ports VPN entrants (TCP 1723, 443 ou UDP 500/4500 + ESP) demeurent nécessaires.
Q : Peut‑on utiliser une IP dynamique WAN avec RRAS ?
R : Oui, mais SSTP demandera un certificat associé à un FQDN public ; utilisez alors un client DDNS (Azure DNS, DynDNS, etc.) pour mettre à jour le nom après chaque changement d’adresse.
Conclusion
Une coupure de connectivité Internet après connexion VPN est presque toujours liée soit à une absence de NAT, soit à une résolution DNS incomplète. En suivant les étapes de diagnostic (nslookup, tracert, vérification de la route par défaut) et en appliquant l’une des deux stratégies Split‑Tunneling ou NAT sur RRAS, vous rétablirez un accès fluide aux ressources internes et externes. Complétez‑le par des redirecteurs DNS, des règles pare‑feu adaptées et un audit régulier des journaux RRAS pour pérenniser la solution.