Attention, lorsque vous configurez l’adresse du serveur VPN en utilisant le SSID vpn-ufc présent sur les bornes de l’Université de Franche-Comté, vous ne devez pas mettre le nom du serveur mais son adresse IP.
ex : 194.57.91.251 au lieu de test.vpn.univ-fcomte.fr
ex : 194.57.91.250 au lieu de vpn1.univ-fcomte.fr
En effet, ce SSID ufc-vpn n’a accès qu’aux serveurs VPN et donc n’a pas accès aux différents serveurs de nom (que ce soit ceux de l’UFC ou de votre provider).
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 :
Le protocole IKE d’échange des certificats entre le serveur et le client ne supporte pas, de la part du serveur, une fragmentation des paquets contenant le certificat. Ainsi, avec une clef de certificat de taille 1024 bits, tout se passe bien, mais si l’on en crée une de 4096 bits, le serveur est incapable de négocier avec le client une connexion IPSEC.
Les serveurs VPN sont donc équipés de certificats avec des clefs de 1024 bits.
Si votre mot de passe ne semble pas fonctionner sur un realm particulier (autre que le realm générique ufc), c’est sans doute dû à un problème d’interprétation du login (donc le mot de passe n’est pas en cause). En effet le login que vous avez sur le realm @ufc (et qui est demandé lors de la création du ticket sur l’ENT) est sans aucun doute différent du login sur le realm que vous voulez atteindre. Veillez, lorsque vous demandez un accès sur un realm autre que @ufc à bien spécifier le login (ex mhamelin pour @ufc et marc.hamelin pour @cri).
George Ou a trouvé un problème sous VISTA (et sous XP service pack 2) lors de la connexion d’un client sur openswan à travers un NAT. Le problème empêche la connexion VPN IPSEC de s’établir.
L’article Configuration serveur : connexion client XP/VISTA donne des précisions importantes sur ce sujet.
Pour corriger cela (si vous avez lu l’article en lien, seul VISTA a besoin d’un changement de la base de registre) un article est paru chez microsoft.
En ce qui nous concerne, il faut ouvrir la base de registre, naviguer jusqu’à HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
(ou avec XP SP2 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec) et créer le DWORD (32-bit) AssumeUDPEncapsulationContextOnSendRule avec la valeur 2
Pour une prise en compte de la nouvelle base de registre, redémarrer Windows.
Un script spécifique lors de la création d’un lien PPPXX à été écrit pour éliminer dans IPTABLES (mangle) les restes des connexions mal fermé. Le problème est l’accumulation dans la tabe mangle de connexion lié au même PPP alors que la connexion en cours à besoin d’un ajout en cours pour sa propre connexion PPP.
Le script effectue donc une élimination de toutes les lignes dans mangle traitant du PPP en cours ; ensuite il y a ajout de la bonne ligne PPP dans la table mangle.
Le fichier se trouve dans : ip-pre-up.d/vpn-pre-connect
Ces deux programmes permettent d’identifier par une surcouche à PPP un utilisateur à travers un lien IPSEC actif.
Au cours des travaux de mise en oeuvre du projet VPN, nous avons souvent oscillé entre les deux, pour plusieurs raisons :
– L2TP n’est plus maintenur officielement
– XL2TP est maintenu
– pour un client L2TP permet une authentification sans passer par un fichier pap-secret avec un mot de passe en clair
– L2TP est en standard dans les distributions LINUX
– L2TP à été modifié est un repository au LIFC le maintient à jour
Lors des tests beta, nous avons remarquer que L2TP du côté serveur tombait régulièrement sans raison et sans information dans les fichiers de logs.
Le serveur est donc recofiguré avec XL2TP.
Côté client L2TP peu être maintenu.
Suite à une erreur de connexion, si on essaye de se reconnecté trop vite on obtient un message d’erreur.
Il suffit d’attendre quelques minutes (3 mns normalement) et de reprendre l’opération de connexion.
Cette erreur assez courante lors d’une connexion en directe (sans NAT) provient principalement de la négociation d’une encapsulation inexistante entre le client et le serveur. Windows cherche à négocier un passage des paquets à travers une encapsulation UDP qui n’étant pas nécessaire, n’a pas été négociée.
On retrouve également cette erreur lors de la connexion avec un certificat déjà utilisé par une autre connexion VPN simultanée.
Il suffit de renouveler l’appel en appuyant sur le bouton « Rappeler ».
Il est possible que l’erreur se produise plusieurs fois de suite, il faut juste insister.
Le fait d’insister n’entraîne pas de problème de black list.
L’erreur 735 est un des rares cas ou windows est assez explicite quand à l’erreur de connexion du VPN.
Vous avez configuré une adresse IP « en dur » au lieu de mettre un choix DHCP.
Dans les propriété TCP/IP de la connexion VPN,
il faut mettre : obtenir automatiquement une adresse ip
et pas : utilisez l’adresse suivante …
