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
Archive for the ‘problèmes utilisateurs’ Category
Problème Windows : connexion filaire OK connexion WIFI NOK
mercredi, mai 21st, 2008Configuration serveur : connexion client XP/VISTA
jeudi, mai 15th, 2008Depuis 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.
Problème WIFI SSID vpn-ufc : DNS / adresse IP
jeudi, mai 15th, 2008Attention, 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).
Problème Windows : Zone Alarm
mardi, mai 13th, 2008Zone 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 :
Problème d’authentification
mardi, mai 6th, 2008Si 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).
Problème windows : erreur 629
vendredi, avril 25th, 2008Suite à 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.
Problème windows : erreur 737
mercredi, avril 23rd, 2008Cette 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.
Problème windows : erreur 735
mardi, avril 22nd, 2008L’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 …
Client Linux et Serveur : options dans sysctl.conf
jeudi, avril 10th, 2008Pour le bon fonctionnement du proxy-arp du serveur VPN,
le fichier /etc/sysctl.conf du serveur VPN doit être configuré comme suit en ajoutant ces options :
net.ipv4.ip_forward=1
net.ipv4.icmp_ignore_bogus_error_responses=1
net.ipv4.conf.all.log_martians=0
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.default.accept_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2
Sans ces options, le proxy-arp du serveur VPN ne fonctionne pas correctement et empêche le client d’accéder à quoi que ce soit hors le serveur VPN lui même.