MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Erreur VPN Windows (code 868) : « le nom du serveur d’accès distant ne s’est pas résolu » — Diagnostic DNS & correctifs RRAS

Erreur VPN Windows (code 868) : « le nom du serveur d’accès distant ne s’est pas résolu » — Diagnostic DNS & correctifs RRAS

Windows Server

Votre VPN RRAS sous Windows Server refuse les connexions extérieures avec le message « The remote connection was not made because the name of the remote access server did not resolve » (code 868) ? Voici un guide concret pour diagnostiquer et corriger rapidement, en ciblant d’abord le DNS public.

Sommaire

Vue d’ensemble

Des utilisateurs ne parviennent plus à établir une connexion VPN depuis l’extérieur, alors que la connexion depuis le LAN continue de fonctionner. Côté client Windows, le message est généralement : The remote connection was not made because the name of the remote access server did not resolve (souvent avec le code 868). Le serveur VPN est un RRAS sur Windows Server 2019, fréquemment hébergé sur une VM jouant aussi les rôles de contrôleur de domaine et DNS interne.

Diagnostic le plus probable : rupture de résolution DNS du nom public du VPN. Dans la grande majorité des cas, l’enregistrement A/CNAME public a disparu, pointe vers la mauvaise IP, la délégation de zone a été modifiée chez le registrar, le DNSSEC est cassé, ou le profil client utilise un nom interne (court ou en .local) non résolvable sur Internet. Sans résolution, l’appel VPN n’atteint jamais votre serveur.

Pourquoi le message oriente vers le DNS

Avant toute négociation (SSTP, IKEv2, L2TP/IPsec), l’hôte client doit convertir le FQDN configuré (p. ex. vpn.exemple.com) en adresse IP. Si la résolution échoue, Windows retourne immédiatement l’erreur, sans établir de session ni toucher aux ports VPN. C’est pourquoi :

  • Un ping qui échoue ne prouve rien, mais une résolution qui échoue explique exactement l’erreur 868.
  • Pour SSTP, même si vous testez l’IP publique à titre temporaire, la connexion finale exigera un certificat dont le CN/SAN correspond au FQDN.
  • Un split-DNS mal aligné (interne ≠ externe) crée des symptômes piégeux : tout marche au bureau (FQDN → IP privée), mais échoue à l’extérieur (FQDN non résolu ou IP inattendue).

Checklist express (depuis un réseau extérieur)

  • Contrôler la résolution publique du FQDN du VPN avec au moins deux résolveurs (Google 8.8.8.8, Cloudflare 1.1.1.1).
  • Comparer le résultat avec la résolution interne (split‑DNS).
  • Vérifier que le profil VPN utilise un FQDN public valide (pas un nom court ni un .local).
  • Si vous venez de corriger le DNS, tenir compte du TTL et de la propagation.
  • Faire un test de contournement à l’IP publique (temporaire) pour confirmer la partie réseau/NAT (surtout IKEv2/L2TP).

Tests détaillés

Vérifier la résolution publique

Depuis un poste hors de votre réseau (4G/5G, domicile, etc.) :

nslookup vpn.exemple.com 8.8.8.8
nslookup vpn.exemple.com 1.1.1.1
nslookup -type=NS exemple.com
nslookup -type=SOA exemple.com

Si possible (outil dig) :

dig +trace vpn.exemple.com

Interprétez les résultats :

  • NXDOMAIN : l’enregistrement n’existe pas publiquement.
  • NOERROR, mais vide : réponse sans A/AAAA ; vérifier la zone.
  • Réponse A/AAAA inattendue : l’IP renvoyée n’est pas votre IP publique actuelle.

Comparer avec l’interne (split‑DNS)

Depuis le LAN ou un serveur interne :

Resolve-DnsName vpn.exemple.com

Cas typique : en interne, le FQDN renvoie une IP privée (p. ex. 10.0.0.10), alors qu’en externe il n’existe pas, ou renvoie une autre IP publique. Il faut aligner les deux visions : même FQDN, IP adaptée au contexte (privée en interne, publique en externe).

Valider le FQDN dans le profil client

Ouvrir les paramètres du profil VPN Windows : le « Nom du serveur » doit être un FQDN public, pas un nom court (ex. VPN‑SRV), ni un suffixe interne, ni un .local (réservé au mDNS, non routable sur Internet).

Gestion du TTL et propagation

Après correction DNS, attendez l’expiration du TTL précédent ou testez via plusieurs résolveurs publics. En production, un TTL de 300–900 s sur le record VPN est un bon compromis entre performance et flexibilité.

Test de contournement rapide

Vous pouvez temporairement renseigner l’IP publique dans le profil pour valider la connectivité réseau/NAT (surtout IKEv2/L2TP). Attention : en SSTP, le certificat doit correspondre au FQDN ; l’usage de l’IP ne servira qu’à vérifier l’ouverture du port 443.

Correctifs par scénario

Enregistrement A/CNAME public absent ou erroné

Créez/corrigez l’enregistrement dans la zone DNS publique chez votre hébergeur/registrar :

Type: A (ou CNAME)
Nom: vpn
Cible: <Votre IP publique (ou CNAME vers l’hôte cible)>
TTL: 300 à 900 s

Évitez de n’avoir que la zone Active Directory interne : la zone publique doit contenir aussi le record VPN (avec l’IP publique).

Mauvaise délégation de zone / serveurs de noms

Si nslookup -type=NS vous renvoie des serveurs de noms inattendus ou incomplets, rétablissez la délégation correcte côté registrar. Assurez-vous que la zone publique servie par ces NS contient bien le record du VPN.

DNSSEC incohérent

Une chaîne DNSSEC cassée provoque des échecs de validation côté résolveurs publics. Corrigez la signature/DS. À défaut, désactivez temporairement la publication DS le temps de réparer. Dans tous les cas, vérifiez ensuite la résolution auprès de 8.8.8.8 et 1.1.1.1.

Split‑DNS mal aligné

Maintenez deux zones séparées :

  • Externe : vpn.exemple.com → <IP publique>.
  • Interne : vpn.exemple.com → <IP privée du RRAS>.

Évitez d’utiliser un FQDN en .local pour le VPN. Standardisez un FQDN public unique et référez‑vous toujours à lui.

Nom interne dans les profils clients

Redéployez les profils avec le FQDN public. Un nom court ou un alias interne ne fonctionnera pas hors du LAN.

Quand le DNS est bon mais ça échoue encore

Si la résolution publique renvoie la bonne IP et que l’erreur persiste, passez aux vérifications suivantes.

NAT/pare‑feu

Confirmez les redirections et l’ACL vers l’adresse interne du serveur RRAS. Vérifiez les ports/protocoles suivants :

TechnologiePorts/ProtocolesTest minimalRemarques
SSTPTCP 443Test-NetConnection vpn.exemple.com -Port 443Nécessite un certificat valide pour le FQDN.
IKEv2UDP 500, 4500Capture/port‑open sur 500/4500NAT‑T via 4500 ; attention aux ALG/NAT symétriques.
L2TP/IPsecUDP 500, 4500, 1701 (+ IPsec)Vérifier 1701 après IPsec OKPrérequis : échange IPsec abouti.
PPTP (déconseillé)TCP 1723 + GRE 471723/TCP + pass‑through GREObsolète et peu sûr ; éviter en production.

Certificat pour SSTP

  • Le CN/SAN doit contenir exactement le FQDN public du VPN.
  • Certificat non expiré, chaîne de confiance complète et émise par une AC reconnue côté clients.
  • Après remplacement, un Restart-Service RemoteAccess peut être nécessaire.

Journaux et traces

  • Serveur : Observateur d’événements → RemoteAccess, RasMan, RasClient.
  • Client : activer les traces : netsh ras set tracing * enabled rem Reproduire le problème netsh ras set tracing * disabled

Important : ipconfig /registerdns ne publie pas de DNS public. Cette commande n’a aucun effet chez votre hébergeur DNS et ne corrige pas un record manquant sur Internet.

Tableau récapitulatif : symptômes ↔ indices

ObservationIndice principalPiste
Erreur 868 immédiate, aucun trafic 443/500/4500 visible côté pare‑feuÉchec de résolutionRecord A/CNAME manquant, délégation/NS, DNSSEC
OK au bureau, KO à l’extérieurSplit‑DNSFQDN interne ≠ externe, IP privée vs publique
Connexion SSTP atteint 443 mais échoue plus tardCertificatCN/SAN ne correspond pas, chaîne incomplète
IKEv2/L2TP ne démarre pas hors LANNAT/ALGPort‑forward manquant, NAT‑T bloqué (4500/UDP)
Fonctionne pour certains FAI, pas d’autresPropagation/TTLRésolveurs encore en cache ou DNSSEC invalidé

Commandes utiles (copier‑coller)

Vérifier la résolution

:: Hors LAN (CMD)
nslookup vpn.exemple.com 8.8.8.8
nslookup vpn.exemple.com 1.1.1.1

\:: Interne (PowerShell)
Resolve-DnsName -Name vpn.exemple.com
Resolve-DnsName -Name vpn.exemple.com -Server 1.1.1.1

Tester l’ouverture de port

# SSTP
Test-NetConnection vpn.exemple.com -Port 443 -InformationLevel Detailed

# Port UDP (approx.) – valider via capture si besoin

# Pour un test plus poussé, utilisez un scanner contrôlé depuis l'extérieur.

Redémarrer le service RRAS (après changement certificat/config)

Restart-Service -Name RemoteAccess

Activer les traces côté client

netsh ras set tracing * enabled

Exemple de corrections DNS

Zone publique (hébergeur/registrar)

; Zone: exemple.com
vpn     300     IN A      203.0.113.42
; ou
vpn     300     IN CNAME  vpn-frontend.exemple.net.

Zone interne (AD‑DNS)

; Zone: exemple.com (interne)
vpn     300     IN A      10.0.0.10   ; IP privée du serveur RRAS

Plan d’action rapide (opérationnel)

  1. Identifier le FQDN officiel du VPN et vérifier sa résolution publique vers la bonne IP.
  2. Corriger la zone DNS publique chez l’hébergeur/registrar si nécessaire (A/CNAME, NS, DNSSEC).
  3. Valider la NAT/ACL vers l’IP interne du serveur RRAS.
  4. Pour SSTP : contrôler le certificat (CN/SAN = FQDN) et redémarrer RRAS si besoin.
  5. Re‑tester depuis un réseau extérieur : Test-NetConnection vpn.exemple.com -Port 443 (SSTP) ou vérifier 500/4500 UDP (IKEv2/L2TP).

Prévention et durabilité

  • Surveillance : sondez régulièrement la résolution DNS du FQDN VPN et l’ouverture des ports depuis l’extérieur.
  • Certificats : automatisez le renouvellement (ACME) et documentez le FQDN exact utilisé par les clients.
  • Architecture : évitez d’exposer une VM cumule RRAS + AD/DNS critique ; privilégiez un serveur membre en DMZ et un DNS secondaire public.
  • Adresses : si l’IP publique est dynamique, mettez en place du Dynamic DNS ou passez à une IP statique ; maintenez un TTL court (300–900 s) pour le record VPN.
  • Documentation : figez le FQDN/ports/flux/NAT dans une fiche d’exploitation et contrôlez après toute intervention réseau.

Foire aux questions (FAQ)

Un ping échoue, dois‑je m’inquiéter ?

Pas forcément. Beaucoup de pare‑feux bloquent l’ICMP. Ce qui compte d’abord : la résolution du FQDN. L’erreur 868 est typiquement liée au DNS, pas à l’ICMP.

Pourquoi ça marche au bureau mais pas chez moi ?

Parce qu’en interne, le FQDN peut pointer vers l’IP privée du serveur (split‑DNS), alors qu’en externe il est absent ou pointe ailleurs. Alignez les zones interne/externe.

Changer le nom du VPN côté client peut‑il suffire ?

Oui, si le profil utilisait un nom interne (ou court). Remplacez‑le par le FQDN public canonique du service VPN.

Dois‑je ouvrir plus de ports ?

Ouvrez seulement ce qui est nécessaire à votre protocole (cf. tableau). Si la résolution DNS est cassée, ouvrir des ports supplémentaires ne changera rien.

Modèle de script de vérification

Un petit script PowerShell pour valider en chaîne le DNS public et le port 443 (SSTP) :

param(
  [Parameter(Mandatory=$true)][string]$VpnFqdn
)

Write-Host "=== Vérification DNS publique ==="
try {
\$public = Resolve-DnsName -Server 1.1.1.1 -Name \$VpnFqdn -ErrorAction Stop
\$ips = (\$public | Where-Object {\$*.Type -in 'A','AAAA'}).IPAddress
if(-not \$ips){ throw "Aucun enregistrement A/AAAA public." }
\$ips | ForEach-Object { Write-Host "  - \$VpnFqdn → \$*" }
} catch {
Write-Error "DNS public KO: \$($\_.Exception.Message)"
exit 1
}

Write-Host "=== Test port 443 (SSTP) ==="
\$result = Test-NetConnection -ComputerName \$VpnFqdn -Port 443 -InformationLevel Detailed
if(\$result.TcpTestSucceeded){
Write-Host "OK: 443/TCP ouvert jusqu'à \$VpnFqdn"
} else {
Write-Error "Échec 443/TCP jusqu'à \$VpnFqdn"
}

Mauvaises pistes fréquentes à éviter

  • Se fier uniquement à « ping » : la couche ICMP ne garantit rien pour le VPN.
  • Lancer ipconfig /registerdns côté serveur en pensant corriger Internet : cette commande n’agit que sur l’AD‑DNS interne.
  • Réinstaller le rôle RRAS avant d’avoir vérifié le DNS public : perte de temps et de configuration.
  • Changer l’IP publique à la volée sans mettre à jour le DNS et le TTL : vous créez une fenêtre d’indisponibilité.

Cas particuliers

Certificat wildcard

Un *.exemple.com peut fonctionner pour SSTP tant que le FQDN (p. ex. vpn.exemple.com) correspond au motif et que la chaîne est de confiance. Évitez cependant les noms alternatifs non documentés.

Environnements à double NAT

Assurez‑vous que la redirection 443/500/4500 est bien chaînée à travers chaque couche de NAT et que le retour fonctionne (NAT loopback/hairpin si besoin pour certains tests). Pour IKEv2/L2TP, vérifiez le NAT‑T (UDP 4500).

IPv6

Si vous exposez un enregistrement AAAA, garantissez que 443/UDP 500/4500 sont joignables en IPv6, sinon supprimez l’AAAA pour éviter des tentatives infructueuses côté clients préférant IPv6.

Liste de contrôle finale

  • Le FQDN du VPN se résout en externe vers votre IP publique actuelle.
  • Le même FQDN se résout en interne vers l’IP privée du serveur, si vous utilisez un split‑DNS.
  • Les ports requis sont ouverts et correctement redirigés.
  • (SSTP) Le certificat est valide, CN/SAN = FQDN public.
  • La propagation DNS et le TTL sont pris en compte.
  • Les profils clients utilisent le FQDN public (pas de nom court ni .local).

Conclusion

Le message « le nom du serveur d’accès distant ne s’est pas résolu » (code 868) pointe quasi systématiquement vers un problème de DNS public. Rétablissez en priorité la résolution du FQDN, puis validez NAT/ports et certificat (SSTP). Une fois le DNS corrigé, la majorité des connexions reprennent immédiatement après propagation.

Windows Server
DNS VPN Windows Server RRAS SSTP IKEv2 Erreur 868
Sommaire