vpn

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

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: base de registre, log, patch, vista, windows
Posted in informations techniques, problèmes utilisateurs | No Comments »

Problème d’utilisation multiple d’un certificat

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: certificat, distinct, utilisation
Posted in problèmes utilisateurs | No Comments »

Linux/Windows : déconnexion de la liaison VPN

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: déconnexion, linux, surcharge, windows
Posted in problèmes utilisateurs | No Comments »

Windows seven

juin 24th, 2009

Pour les heureux possesseur de Windows Seven (Beta ?!), la procédure à suivre pour l’installation du VPN est rigoureusement la même que celle de VISTA.

Tags: seven, windows
Posted in Informations utilisateurs | No Comments »

Problème windows VISTA : passage en veille

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: erreur, l2tp, vista, windows
Posted in problèmes utilisateurs | No Comments »

Problème Windows : nom ou IP du serveur VPN ?

mai 19th, 2009

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

Tags: ip, nom, vista, windows
Posted in Informations utilisateurs | No Comments »

GNU Linux Magazine France

mai 19th, 2009

Le premier d’une série de quatre articles consacrés à la mise en oeuvre de notre solution VPN pour l’UFC a été publié dans le numéro 116 de GNU Linux Magazine France (GLMF).

Tags: article, GLMF, presse
Posted in informations techniques | 5 Comments »

Linux : outils

avril 28th, 2009

Dans la boite à outils que propose Linux nous pouvons trouver :
iwconfig
dhclient

iwconfig permet de voir la configuration d’une interface WIFI …
iwconfig eth1 eth1 IEEE 802.11b ESSID:"ufc-personnels" Nickname:"ipw2100" ...

… ou de la reconfigurer :

iwconfig eth1 essid ufc-vpn

iwconfig eth1 eth1 IEEE 802.11b ESSID:"ufc-vpn" Nickname:"ipw2100" ...

et l’outils dhclient vous permet de récupérer via DHCP une adresse IP :

Listening on LPF/eth1/00:04:23:96:c2:09 Sending on LPF/eth1/00:04:23:96:c2:09 Listening on LPF/eth0/00:06:1b:d8:c4:cb Sending on LPF/eth0/00:06:1b:d8:c4:cb Sending on Socket/fallback DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4 DHCPOFFER from 172.21.7.254 DHCPREQUEST on eth1 to 255.255.255.255 port 67 DHCPACK from 172.21.7.254 bound to 172.21.7.231 -- renewal in 5416 seconds.

Tags: dhclient, iwconfig, linux, outils
Posted in informations techniques, Informations utilisateurs | No Comments »

Problème Linux : certificat non reconnu

mars 19th, 2009

Un certificat non reconnu provoque est visible dans les logs du serveur /var/log/auth.log
Après la séquence de négociation correcte :
Mar 18 13:24:54 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: responding to Main Mode from unknown peer 172.21.7.202 Mar 18 13:24:54 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1 Mar 18 13:24:54 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: STATE_MAIN_R1: sent MR1, expecting MI2 Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2 Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: STATE_MAIN_R2: sent MR2, expecting MI3

Et l’erreur proprement dite :
Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: Main mode peer ID is ID_DER_ASN1_DN: 'C=FR, ST=Franche-Comte, O=UFC, OU=CRI, CN=choucroute, E=vpn-master@univ-fcomte.fr' Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: no crl from issuer "C=FR, ST=Franche-Comte, L=Besancon, O=UFC, OU=CRI, CN=CAvpn, E=vpn-master@univ-fcomte.fr" found (strict=no) Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: no suitable connection for peer 'C=FR, ST=Franche-Comte, O=UFC, OU=CRI, CN=choucroute, E=vpn-master@univ-fcomte.fr' Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: sending encrypted notification INVALID_ID_INFORMATION to 172.21.7.202:500
L’interprétation de l’erreur est assez simple puisque nous voyons que le certificat de choucroute contient OU=CRI ce qui n’est pas une valeur attendu (LINUX, XP, MACOS)

Tags: certificat, linux, problème
Posted in Informations utilisateurs | No Comments »

Problème Linux : Certificat cacert.pem

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: cacert, linux, problème, vérification
Posted in problèmes utilisateurs | No Comments »

vpn