Lorsqu’un portable sous VISTA passe en veille ou que celui-ci est fermé, si la connexion VPN n’a pas été close avant, certains descripteurs utilisé par L2TP sur la machines VISTA reste ouvert. Cela a pour conséquence qu’il devient impossible d’ouvrir une nouvelle connexion L2TP vers le serveur VPN. VISTA indique alors l’erreur 789.
il semble que sous VISTA, il faille écrire l’adresse IP du serveur VPN (194.57.91.250) et non son nom (vpn1.univ-fcomte.fr) pour que la connexion s’établisse correctement.
Il est possible de corriger cela en faisant la manipulation suivante :
Dans la fenêtre de connexion, bouton “propriété”, onglet “gestion du réseau”, “paramètre IPSEC”, il faut décocher “vérifier les attributs Nom et Utilisation des du certificat du serveur”.
Comme nous le conseillons ici ou là, nous vous laissons en téléchargement le petit script qui modifie la base de registre pour VISTA : patch-vpn-ufc-vista.reg
Petite explication de la table de routage d’une machine Windows après une connexion VPN depuis une connexion WIFI.
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
passerelle du réseau WIFI dans lequel vous vous trouvez
0.0.0.0 0.0.0.0 172.21.23.254 172.21.23.253 4250
passerelle du réseau du REALM VPN dans lequel vous vous trouvez => grosse flèche rouge
0.0.0.0 0.0.0.0 On-link 172.20.179.63 26
loopback
127.0.0.0 255.0.0.0 On-link 127.0.0.1 4531
127.0.0.1 255.255.255.255 On-link 127.0.0.1 4531
127.255.255.255 255.255.255.255 On-link 127.0.0.1 4531
votre adresse locale dans le REALM VPN =>
172.20.179.63 255.255.255.255 On-link 172.20.179.63 281
définition du réseau WIFI
172.21.23.128 255.255.255.128 On-link 172.21.23.253 4506
votre adresse locale dans le WIFI
172.21.23.253 255.255.255.255 On-link 172.21.23.253 4506
broadcast dans le WIFI
172.21.23.255 255.255.255.255 On-link 172.21.23.253 4506
Comment joindre le serveur VPN => route obligatoire => grosse flèche noire
194.57.89.105 255.255.255.255 172.21.23.254 172.21.23.253 4251
multicast
224.0.0.0 240.0.0.0 On-link 127.0.0.1 4531
224.0.0.0 240.0.0.0 On-link 172.21.23.253 4508
224.0.0.0 240.0.0.0 On-link 172.20.179.63 26
broadcast générique
255.255.255.255 255.255.255.255 On-link 127.0.0.1 4531
255.255.255.255 255.255.255.255 On-link 172.21.23.253 4506
255.255.255.255 255.255.255.255 On-link 172.20.179.63 281
===========================================================================
Le flèche verte indique le trajet de l’information pour aller sur un serveur dans l’UFC.
La documentation windows a été validée pour XP et VISTA
config_windows-xp-20081020
config_windows-vista-20081020
La documentation MACOS a été validée pour TIGER et LEOPARD
config_macos-20081020
La documentation Linux a été validée pour DEBIAN 4.0, UBUNTU 7.10
config_linux-20081127
Références utiles :
– site du CRI
– site du VPN
– pour linux le site de Jacco de Leeuw
Si l’erreur à la connexion VPN est : “Impossible de trouver un certificat valide”, vous devez suivre les instructions suivantes :
– enlever tous les certificats de la machine
– enlever les autorités de certification
– remettre le certificat que l’on vous a donné (VPN UFC)
– remettre les autorités de certification (normalement celui du VPN UFC est dans le certificat délivré => automatique)
Re-essayez une connexion VPN
L’erreur 691 de windows indique que vous vous êtes trompé dans le login (user ou realm) ou de mot de passe :
Mon Aug 01 14:08:10 2008 : Auth: Login incorrect: [user@realm] (from client vpnX port 0 cli aaa.bbb.ccc.ddd)
si votre connexion filaire fonctionne parfaitement bien et qu’en wifi vous n’arrivez pas à joindre le serveur VPN (code erreur windows 698…), il est fort possible que vous ayez un client VPN type “NETGEAR VPN CLIENT” déjà configuré sur votre machine. Celui-ci n’empêche pas la connexion filaire met prend la main sur les connexions WIFI
Depuis la sortie de VISTA SP1, la connexion IPSEC ne s’effectue plus correctement car il manque une commande (forceencaps=yes) dans la configuration des connexions pour les clients XP/VISTA.
Si, dans la configuration du serveur nous modifions légèrement la connexion pour les clients XP/VISTA en ajoutant :
conn vpn-l2tp-XP
# force l'encapsulation en UDP
forceencaps=yes
alors la connexion d’un VISTA SP1 fonctionne.
De fait, il faudra faire attention en cas de problème de connexion à bien ajouter dans REGEDIT la valeur (pour VISTA) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
(pour XP) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec valeur DWORD AssumeUDPEncapsulationContextOnSendRule à 2 comme cela est spécifié dans l’article Problème VISTA/XP SP2 : modification de la base de registre
Pour le moment nous avons deux choix au niveau du serveur :
– imposer la manipulation de regedit pour les clients XP et garder un type de connexion commune pour XP et VISTA
– régénérer des certificats pour les clients VISTA et créer une connexion spécifique pour VISTA et conserver la connexion XP actuelle.
Le choix sera déterminé semaine 21 suivant les essais faits avec XP SP2 et SP3 et VISTA sans SP1 et avec SP1. Pour le moment seuls les clients XP SP2 et VISTA sans SP1 peuvent utiliser les serveurs IPSEC.
Les résultats des tests démontrent que pour Windows XP SP1/SP2 et SP3 nous pouvons conserver la même configuration client et serveur => aucun changement à effectuer sur les postes clients XP ni de changement de certificat.
Pour Windows VISTA sans SP1 ou avec SP1, il faut mettre à jour la base de registre.
Zone Alarm peut vous poser des soucis de connexion car établir un VPN est une action de connexion sur un site distant via un logiciel non enregistré par Zone Alarm.
Pour cela il suffit d’ajouter le serveur dans les machines autorisées pour une connexion (ajout d’une adresse IP) :
Le même problème surviendra pour les accès sur des réseaux intérieurs à l’UFC via le VPN :
il faudra encore une fois ajouter ce réseau à la liste des réseaux sécurisés :
