Archive for the ‘problèmes utilisateurs’ Category

« Older Entries
Newer Entries »

Problème Linux : Kernel 2.6.31

jeudi, novembre 26th, 2009

Le kernel 2.6.31 que l’on retrouve dans ubuntu 9.10 et suze 11.2 pose des problèmes avec le VPN.
Celui-ci semble se monter correctement, mais aucune communication n’est alors possible, puis au bout d’une minute ou deux la connexion tombe.
Si vous avez eu le temps de taper une commande ifconfig vous aurez alors pu voir la connexion ppp0 avec 100 000 000 d’octet émis et 0 en réception.

Le problème est dû au noyau linux 2.6.31 dans lequel nombre d’API ont changé et qui ne sont donc plus compatible avec les différents logiciels devant utilisé la pile IPSEC (cf net: remove COMPAT_NET_DEV_OPS ou il semble que deux ou trois choses se soit faites … trop vite).

Une recompilation du noyau sur la version 2.6.30 remet les choses en l’état, mais cette opération étant délicate, nous ne la conseillons pas.
Normalement la version d’openSWAN 2.6.24rc2 devrait prendre en compte la modification de l’API du noyau.

Confirmation de notre collègue Michel Devel : <<Après installation de Openswan Version 2.6.ikev2-200950.git-g80b1ff8a (2.6.24.rc3), l’accès VPN depuis opensuse 11.2 (kernel 2.6.31) fonctionne.>>

En attendant la sortie corrigée d’Openswan, vous pouvez toujours appliquer le script de Jean-Michel Carricand (https://vpn.univ-fcomte.fr/?p=97)

Tags:, , , ,
Posted in problèmes utilisateurs | No Comments »

windows VISTA : erreur 789 ou 835

mercredi, octobre 21st, 2009

cette erreur (789, 835) est dû au fait que l’on mette “vpn.univ-fcomte.fr” à la place de l’IP du serveur VPN : 194.57.91.250 (sur besançon).
La correction de la configuration fait rentrer dans l’ordre la connexion VPN.

sur le serveur VPN, les logs indiquent :

packet from 172.21.7.86:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000006]
received Vendor ID payload [RFC 3947] method set to=110
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 110
ignoring Vendor ID payload [FRAGMENTATION]
ignoring unknown Vendor ID payload [fb1de3cdf341b7ea16b7e5be0855f120]
ignoring Vendor ID payload [Vid-Initial-Contact]
ignoring unknown Vendor ID payload [e3a5966a76379fe707228231e5ce8652]
responding to Main Mode from unknown peer 172.21.7.86
only OAKLEY_GROUP_MODP1024 and OAKLEY_GROUP_MODP1536 supported. Attribute OAKLEY_GROUP_DESCRIPTION
only OAKLEY_GROUP_MODP1024 and OAKLEY_GROUP_MODP1536 supported. Attribute OAKLEY_GROUP_DESCRIPTION
transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
STATE_MAIN_R1: sent MR1, expecting MI2

Tags:, , , , ,
Posted in Informations utilisateurs, problèmes utilisateurs | 2 Comments »

Problème VISTA : la connexion ne fonctionne pas, pas de message d’erreur

mardi, octobre 20th, 2009

Sous VISTA si le petit patch de la base de registre est mal appliqué (ou la machine n’est pas rebooté), il est possible que la connexion VPN échoue sans aucun message d’erreur.

Néanmoins dans les logs du serveur VPN nous aurons :

STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
STATE_QUICK_R2: IPsec SA established {ESP=>0xd3e37be6 <0xb8baa9ac xfrm=AES_128-HMAC_SHA1 NATD=172.20.10.58:4500 DPD=none} received Delete SA(0x7e993ed9) payload: deleting IPSEC State #61676 received and ignored informational message

Un log de connexion réussi :

STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
STATE_QUICK_R2: IPsec SA established {ESP=>0x1a850fb1 <0x72559a9e xfrm=AES_128-HMAC_SHA1 NATD=172.21.7.183:4500 DPD=none}

Tags:, , , ,
Posted in informations techniques, problèmes utilisateurs | No Comments »

Problème d’utilisation multiple d’un certificat

lundi, août 24th, 2009

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.

Tags:, ,
Posted in problèmes utilisateurs | No Comments »

Linux/Windows : déconnexion de la liaison VPN

dimanche, juillet 12th, 2009

Dans 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).

Tags:, , ,
Posted in problèmes utilisateurs | No Comments »

Problème windows VISTA : passage en veille

mercredi, mai 27th, 2009

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.

Tags:, , ,
Posted in problèmes utilisateurs | No Comments »

Problème Linux : Certificat cacert.pem

vendredi, février 27th, 2009

Si 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

Tags:, , ,
Posted in problèmes utilisateurs | No Comments »

Problème Linux : Opensuse 11

mardi, janvier 20th, 2009

Les 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

Tags:, ,
Posted in problèmes utilisateurs | No Comments »

Problème Linux : erreur d’authentification L2TP/XL2TP

lundi, janvier 12th, 2009

Lors 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.

Tags:
Posted in problèmes utilisateurs | No Comments »

problème Linux : route par défaut surnuméraire

lundi, décembre 8th, 2008

avant 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

Tags:, ,
Posted in problèmes utilisateurs | No Comments »

« Older Entries
Newer Entries »