Valeur de registre NAT-T sous Windows : vérifier d’abord la topologie

Une connexion VPN Windows échoue, une recherche renvoie une valeur de registre et cette valeur est appliquée avec un redémarrage. Cette séquence fonctionne parfois et n’explique jamais rien. Le paramètre en question répond à une question sur l’emplacement du serveur par rapport à un équipement NAT, et il n’a aucun sens tant que vous ne savez pas quel protocole a échoué et à quel stade.

Ce que la valeur sélectionne réellement

AssumeUDPEncapsulationContextOnSendRule détermine si une implémentation IPsec de Windows tentera d’établir des associations avec un pair derrière un équipement NAT. La valeur par défaut documentée 0 n’autorise pas ce cas, 1 l’autorise lorsque le serveur est le côté derrière le NAT, et 2 couvre la traduction des deux extrémités. Ce sont des affirmations de topologie sur qui se trouve où.

Lus comme une séquence, les nombres décrivent de plus en plus de traduction, non de plus en plus de fiabilité. Mettre 2 sur un réseau où rien n’est traduit ne rend pas la connexion plus rapide ou plus stable et ne répare pas un échec d’authentification. Le guide NAT de Microsoft pour L2TP/IPsec documente la stratégie et son contexte historique de plateforme. Confrontez ce contexte à la version et au rôle de Windows que vous exécutez réellement, car un document qui a survécu à plusieurs versions n’est pas une affirmation sur chaque build actuel.

Aligner la topologie avant le nombre

Dessinez le chemin et marquez les points de traduction : le client est-il derrière un routeur domestique, le serveur derrière un répartiteur de charge ou un pare-feu qui réécrit les adresses, et l’une des extrémités est-elle derrière une traduction de l’opérateur que vous ne contrôlez pas. Ce n’est qu’après ce dessin que vous pouvez décider si la valeur s’applique, et à quelle extrémité.

L’affirmation selon laquelle les versions actuelles de Windows Server seraient simplement livrées avec la traversée NAT désactivée est trop large pour agir dessus. Ce qui compte, c’est la stratégie de votre système, la topologie devant lui et l’échange qui a échoué, dans cet ordre. Si les deux extrémités ont des adresses publiques, le paramètre n’est pas votre problème. Regardez plutôt la proposition, le certificat ou le compte, et laissez le registre tranquille.

Vérifier d’abord le stade de l’échec

L2TP/IPsec produit au moins trois échecs distincts : le pair est inaccessible, la protection IPsec ne peut pas être établie, et l’authentification de l’utilisateur PPP est rejetée une fois le tunnel existant. Un compte rejeté ne se répare pas en changeant la stratégie NAT, et une divergence de propositions ne se répare pas par un redémarrage.

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

Un délai d’attente sans réponse suggère une joignabilité ou un filtrage plutôt qu’une stratégie. Un rejet rapide avec un message de proposition pointe vers les algorithmes. Un échec après la montée du tunnel relève du stade d’authentification, qui est un autre propriétaire et une autre correction.

SSTP sur HTTPS et IKEv2 natif ont leurs propres journaux et leurs propres contrôles. Rien de tout cela ne devient un cas de traversée NAT simplement parce que cela tourne aussi sous Windows.

Faire la modification avec un chemin de retour

Si la stratégie documentée et la topologie observée l’exigent toutes deux, notez la valeur précédente, appliquez la modification via la configuration gérée et non par un script par profil, et planifiez le redémarrage. Sur un serveur qui porte d’autres charges de travail, ce n’est pas une modification anodine.

L’équipement NAT doit encore transporter le trafic encapsulé et le trafic de retour. Une valeur de registre ne crée aucune règle de transfert, n’aligne aucune proposition et ne valide aucune identité, si bien qu’une connexion qui se met à fonctionner après la modification peut fonctionner pour une raison entièrement différente. Retestez le protocole d’origine avec la topologie d’origine, puis notez quel stade a échoué et pourquoi la valeur était censée y remédier. Cette phrase est ce qui transforme une rumeur d’internet en une configuration que vous pouvez défendre.