MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Résoudre la perte d’Internet et d’accès réseau via VPN RRAS sur Windows Server 2019

Résoudre la perte d’Internet et d’accès réseau via VPN RRAS sur Windows Server 2019

Windows Server

Introduction : Vous vous connectez bien au VPN RRAS de votre Windows Server 2019, mais les lecteurs réseau, SQL, Sage et même Internet restent injoignables ? Découvrez les vérifications clés (NAT, DNS, routage, pare‑feu) pour rétablir l’accès complet, étape par étape.

Sommaire

Vue d’ensemble du problème

Lorsque Routing and Remote Access Service (RRAS) est configuré comme serveur VPN, il devient le point d’entrée de tout le trafic des postes distants. Il arrive pourtant que, juste après l’authentification, l’utilisateur puisse ouvrir une session RDP sur le contrôleur de domaine, mais perde :

  • les lecteurs réseau : l’Explorateur Windows affiche une croix rouge ;
  • les applications métiers telles que SQL Server ou Sage X3 ;
  • l’accès à Internet : ping vers 8.8.8.8 ou Google.com en échec ;
  • la messagerie MAPI/SMTP.

La machine semble enfermée dans le LAN, privée d’Internet et de plusieurs services internes. Les causes sont presque toujours liées à un mauvais routage, à l’absence de NAT ou à une configuration DNS incomplète.

Tableau récapitulatif des axes de vérification

Axe de vérificationQue contrôler / corriger ?Pourquoi ?
1. Routage et NAT sur le serveur RRAS• Activer « IP Routing » et configurer NAT sur l’interface reliée à Internet.
• Vérifier qu’une route par défaut (0.0.0.0/0) pointe vers la passerelle du FAI.
• En full‑tunnel, s’assurer que le pool d’adresses des clients est translaté vers l’extérieur.		Sans NAT ni route par défaut, le trafic sortant des clients se bloque au serveur RRAS.
2. Split‑tunneling vs. full‑tunnel• Dans les propriétés de la connexion VPN côté client, cocher/décocher « Utiliser la passerelle par défaut sur le réseau distant ».
• Split‑tunnel : seul le trafic interne passe par le VPN.
• Full‑tunnel : tout transite par le VPN → NAT indispensable.		Un réglage inapproprié entraîne soit l’absence d’Internet (full‑tunnel sans NAT), soit l’impossibilité d’atteindre les réseaux internes (split‑tunnel mal routé).
3. DNS• Attribuer via RRAS le ou les serveurs DNS internes.
• Autoriser la récursion ou définir des redirecteurs publics.
• Pousser un suffixe DNS de recherche.		SMB, SQL/Sage et RDP reposent sur la résolution de noms ; un DNS défaillant fait croire que les ressources sont hors‑ligne.
4. Pare‑feux (Windows & périphériques périmétriques)• Ouvrir HTTP 80, HTTPS 443, SMB 445, SQL 1433, ports Sage.
• Contrôler qu’aucune règle ne bloque le sous‑réseau attribué aux clients VPN.		Un filtrage sélectif peut couper un service tout en laissant les autres fonctionner.
5. Autorisations et sous‑réseaux• Inclure le pool VPN dans les ACL / permissions.
• Mettre à jour les listes d’adresses autorisées dans SQL.		Sans ces mises à jour, l’accès logique est refusé malgré une connectivité physique valide.
6. Tests de diagnostic• Côté client : ipconfig /all, route print, tracert, nslookup.
• Côté serveur : journal RRAS et Get-EventLog.		Permettent de localiser l’étape où le trafic échoue.

Étapes de résolution détaillées

1. Activer le rôle routage et mettre en place le NAT

Dans Gestionnaire de serveur › Outils › Routage et accès distant :

  1. Clic droit sur le nom du serveur › Configurer et activer le routage et l’accès distant.
  2. Sélectionner NAT et accès VPN. L’assistant crée automatiquement les composants RAS et NAT.
  3. Dans les propriétés de l’interface publique, cocher « Activer NAT » et « Translater l’adresse de cet ordinateur sur le réseau public ».
  4. Confirmer que la route 0.0.0.0/0 apparaît dans la table de routage, pointant vers la passerelle du FAI.

Astuce : Utilisez Get-NetRoute -DestinationPrefix 0.0.0.0/0 pour valider la présence de la route par défaut.

2. Choisir judicieusement entre split‑tunnel et full‑tunnel

Ouvrez les Paramètres IP v4 de la connexion VPN dans Windows :

  • Full‑tunnel : cochez « Passerelle par défaut sur le réseau distant ».
    ➔ Tout le trafic passe par le serveur VPN, ce qui simplifie la sécurité (filtrage centralisé) mais exige un NAT bien configuré.
  • Split‑tunnel : décochez la case.
    ➔ La navigation Internet reste locale, seul le trafic interne traverse le VPN. Il faut alors définir des routes statiques ou des plages IP précises dans les paramètres RRAS pour éviter les fuites de données.

Bonnes pratiques : documentez la stratégie retenue et déployez‑la via GPO pour éviter les différences de comportement entre utilisateurs.

3. Vérifier et renforcer la configuration DNS

Les symptômes d’un DNS mal configuré sont souvent :

  • Lecteurs réseau marqués « hors‑connexion » alors que le ping par IP fonctionne ;
  • Échec de nslookup intranet.local avec un timeout ;
  • Navigation Internet bloquée en full‑tunnel (les DNS publics ne sont pas joignables).

Sur le serveur DNS interne :

  1. Ouvrez la console DNS.msc.
  2. Dans les propriétés du serveur, onglet Redirecteurs, ajoutez une IP publique (ex. 1.1.1.1) ou cochez « Activer la récursion ».

Dans la console RRAS, sous IPv4 › Stratégies d’adressage, renseignez le serveur DNS interne afin que le client le reçoive via DHCP RAS.

4. Examiner les pare‑feux Windows et périmétriques

Un blocage applicatif est souvent confondu avec un problème réseau. Vérifiez donc :

  • Windows Defender Firewall sur le serveur d’application et sur le RRAS ;
  • Les règles de bordure (firewall UTM, SD‑WAN, etc.) ciblant le sous‑réseau VPN.

Côté Windows, lister les règles entrantes via PowerShell :

Get-NetFirewallRule -Direction Inbound -Action Block `
    | Where {{$_.DisplayName -like "*SQL*"}} `
    | Format-Table DisplayName, Enabled

Pour un test rapide, basculez temporairement le profil de firewall RRAS en « Domaine » (où moins de ports sont bloqués) et refaites vos essais.

5. Aligner les ACL et listes d’adresses autorisées

Les adresses distribuées aux clients VPN proviennent souvent d’un pool en 10.10.0.0/24 alors que le LAN interne est en 192.168.0.0/24. Sans mettre à jour :

  • les permissions NTFS (lecteurs réseau : partages et dossiers NTFS) ;
  • les listes Firewall Allowed IPs dans SQL ;
  • les restrictions d’hôte Sage ;

…les services refuseront la connexion même si le ping répond. D’où l’importance d’étendre toutes les ACL au sous‑réseau VPN.

6. Utiliser une démarche de diagnostic structurée

Sur le poste client, exécutez :

:: Vérifier l'adresse IP et la passerelle
ipconfig /all

\:: Visualiser la table de routage
route print

\:: Tester DNS et connectivité
nslookup intranet.local
ping 192.168.0.10
tracert 8.8.8.8

Sur le serveur RRAS :

# PowerShell – journalisation RRAS
Get-EventLog -LogName System -Source RemoteAccess -Newest 50

# Activer le mode trace détaillé

netsh ras set tracing \* enabled

Ces journaux mettent en lumière les erreurs : Error 720 – No PPP Control Protocols Configured, Error 20209 – The specified connection could not be found, etc.

Questions fréquentes (FAQ)

« Dois‑je redémarrer le serveur RRAS après chaque modification ? »

Pas toujours. Changer une route ou une règle NAT est pris en compte immédiatement ; en revanche, toute modification du rôle VPN (type de tunnel, authentification PEAP vs. EAP‑TLS) nécessite souvent un redémarrage du service RemoteAccess.

« Quelles sont les meilleures pratiques de sécurité pour RRAS ? »

  • Certificat TLS valide émis par votre PKI ou une AC publique.
  • Chiffrement fort (EAP‑TLS, IKEv2 AES‑256‑GCM).
  • Journalisation centralisée dans un SIEM.
  • MFA via Azure AD NPS extension lorsque c’est possible.

« Comment limiter la bande passante consommée par les utilisateurs VPN ? »

RRAS ne gère pas nativement la QoS par utilisateur. On peut :

  1. Appliquer des stratégies QoS (Gpedit.msc) côté poste.
  2. Mettre en place une file d’attente sur le firewall (traffic shaping basé sur le sous‑réseau VPN).

Aller plus loin : monitoring et haute disponibilité

Surveiller un VPN n’est pas qu’une question de latence. Pensez à :

  • PerfMon : compteurs RAS Port pour le nombre de sessions actives.
  • Task Scheduler : script PowerShell qui envoie une alerte e‑mail lorsque la bande passante dépasse un seuil.
  • Failover Cluster : RRAS peut être mis en cluster NLB, mais prévoyez des licences CAL RDS supplémentaires si vous concentrez le trafic RDP.

Bonnes pratiques synthétisées

« Le VPN est un nouveau segment réseau. Accordez‑lui les mêmes soins qu’au LAN : routage, DNS, pare‑feu, ACL et supervision. »

En résumé, 90 % des pertes de connectivité proviennent d’un triangle NAT / DNS / routes. Passez‑le systématiquement en revue, validez chaque couche avec des commandes simples (ping, tracert, nslookup) et n’oubliez pas de mettre à jour vos pare‑feux ainsi que vos listes d’accès.

Check‑list opérationnelle “première intervention”

Sauvegardez‑la et collez‑la dans votre logiciel de ticketing :

  1. Utilisateur impacté (login, IP VPN, horaire) ;
  2. Résolution DNS interne fonctionnelle ? nslookup dc01.lan
  3. Ping vers IP interne et externe successful ?
  4. Table de routage correcte (0.0.0.0/0 et réseaux LAN) ?
  5. NAT activé sur l’interface WAN du RRAS ?
  6. Ports nécessaires ouverts (445, 1433, 80/443) ?
  7. Adresse IP VPN présente dans les ACL SQL / Fichiers / Sage ?
  8. Redémarrage contrôlé du service RemoteAccess effectué ?
  9. Logs RRAS et NPS analysés pour l’ID de connexion.

Conclusion

Une panne VPN qui « semble » complexe est souvent due à un élément manquant : NAT absent, DNS interne non fourni ou route par défaut omise. En respectant la méthodologie décrite, vous disposerez d’un diagnostic structuré et reproductible. Votre VPN RRAS sur Windows Server 2019 redeviendra fiable, performant et sécurisé.

Windows Server
DNS VPN NAT troubleshooting RRAS Windows Server 2019
Sommaire