Attention lorsque vous avez plusieurs machines qui possèdent le même certificat.
L’utilisation du même certificat depuis deux machines distincts (même avec deux adresses IP distincts) ne sera pas possible. La deuxième connexion sera coupé toutes les 10 secondes environ par le serveur VPN.
Le système client ré-essayant de se connecter automatiquement, cela vous donnera une impression de marche partiel.
Archive for the ‘problèmes utilisateurs’ Category
Problème d’utilisation multiple d’un certificat
lundi, août 24th, 2009Linux/Windows : déconnexion de la liaison VPN
dimanche, juillet 12th, 2009Dans certain cas, il y a perte de connexion VPN sans erreur visible dans les fichiers de logs.
Deux pistes :
– coupure temporaire du lien réseau (qui peut arriver avec le WIFI, ou plus rarement une panne de l’opérateur) ;
– surcharge importante du lien par un ordinateur tièrce (si votre portable est en VPN que votre machine de bureau sans VPN effectue un gros transfert de fichier en utilisant toute la bande passante).
Problème windows VISTA : passage en veille
mercredi, mai 27th, 2009Lorsqu’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.
Problème Linux : Certificat cacert.pem
vendredi, février 27th, 2009Si vous avez le message suivant dans vos log /var/log/auth.log :
Feb 27 11:42:14 cri-29 pluto[6156]: "ufc-vpn" #1: issuer cacert not found
... pluto[6156]: "ufc-vpn" #1: X.509 certificate rejected
... pluto[6156]: "ufc-vpn" #1: no RSA public key known for '194.57.91.250'
C’est que le fichier /etc/ipsec.d/cacerts/cacert.pem n’est pas le bon ou qu’il n’est pas dans ce répertoire.
Pour vérifier le cacert :
openssl x509 -in /etc/ipsec.d/cacerts/cacert.pem -noout -subject
qui vous donne :
subject= /C=FR/ST=Franche-Comte/L=Besancon/O=UFC/OU=CRI/CN=CA-vpn/
emailAddress=vpn-master@univ-fcomte.fr
Problème Linux : Opensuse 11
mardi, janvier 20th, 2009Les versions d’opensuse 11 ne prennent pas en compte l’application de la route vers le serveur VPN lors de l’établissement du cannal VPN. De fait la liaison finit par s’interrompre au bout de quelques minutes (lié au timeout des connexions).
Il faut donc ajouter manuellement la route :
route add -host le_serveur_vpn gw votre_passerelle_actuelle
Problème Linux : erreur d’authentification L2TP/XL2TP
lundi, janvier 12th, 2009Lors de l’établissement de la connexion L2TP, il est possible que le serveur indique dans les logs
sent [LCP TermReq id=0x3 "peer refused to authenticate"]
Cette ligne indique une erreur dans le fichier /etc/l2tp/l2tp.conf ou /etc/xl2tp/xl2tp.conf.
Il faut impérativement avoir :
require authentication = no
à la place de
refuse authentication = yes
puisque le premier n’impose pas d’authentification mais ne la refuse pas, tandis que la seconde refuse toute authentification.
problème Linux : route par défaut surnuméraire
lundi, décembre 8th, 2008avant d’activer le VPN vous avez des routes du style :
172.21.7.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 172.21.7.254 0.0.0.0 UG 0 0 0 eth1
Une fois activé le VPN (sur l’interface WIFI) vous avez :
194.57.91.250 172.21.7.254 255.255.255.255 UGH 0 0 0 eth1
192.168.255.202 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
172.21.7.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
Mais il est possible qu’une fois activé ipsec vous ayez les routes suivantes en sus :
0.0.0.0 0.0.0.0 128.0.0.0 U 0 0 0 eth1
128.0.0.0 0.0.0.0 128.0.0.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth1
Les deux premières routes sont complètement inutile et nuisible à votre connexion. Il faut donc s’en débarrasser avec les commandes suivantes :
route del -net 128.0.0.0 netmask 128.0.0.0
route del -net 0.0.0.0 netmask 128.0.0.0
Vous pouvez aussi aller modifier le fichier /etc/ipsec.conf en décommentant la ligne suivante :
include /etc/ipsec.d/examples/no_oe.conf
Problème Linux : Interface WIFI capricieuse
lundi, décembre 8th, 2008Si lors d’un test de connexion comme :
ping 194.57.89.208
vous obtenez la réponse :
connect: Resource temporarily unavailable
c’est que votre interface WIFI est momentanément inutilisable. En général cela ne dure que quelques secondes, mais si ce problème persiste il faut vérifier dans les logs que l’interface WIFI est bien présente.
Il est possible que votre portable demande une action manuelle pour démarrer le WIFI (bouton ON/OFF wifi/blutooth)
Vous pouvez aussi aller modifier le fichier /etc/ipsec.conf en décommentant la ligne suivante :
include /etc/ipsec.d/examples/no_oe.conf
Problème Linux : trop de route par défaut
lundi, décembre 8th, 2008Si vous avez plusieurs routes par défaut, cela viens sans aucun doute que vous avez activez (volontairement ou non) le WIFI plus l’interface filaire de votre portable.
Dans ce cas, vous voyez quelque chose du style :
0.0.0.0 194.57.89.254 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 172.21.7.254 0.0.0.0 UG 0 0 0 eth1
Le processus ipsec ne pourra pas démarrer, car il ne saura pas quel passerelle utiliser pour connecter le serveur VPN.
Dans ce cas, il faut donc fermer une connexion (filaire ou wifi au choix) et relancer ipsec.