Posts Tagged ‘l2tp’

Problème windows : erreur d’authentification L2TP

lundi, novembre 23rd, 2009

Si les logs du serveur VPN (/var/log/syslog) indique pour une connexion XP/VISTA/SEVEN l’erreur :

peer refused to authenticate: terminating link
sent [LCP TermReq id=0x3 "peer refused to authenticate"]

c’est qu’il faut vérifier en plus les logs du serveur RADIUS.
Si ceux-ci indique :

Info: rlm_perl: Entry xxxxx@xxxxx/194.57.91.250 not found in database (post_auth)

c’est que l’on a oublié de rentrer dans la base de données des ACL la règle autorisant la personne à se connecter sur le realm voulu.

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.

Problème Linux : route vers le serveur VPN absente

vendredi, mai 23rd, 2008

Lors de l’établissement L2TP/PPP entre le client et le serveur, L2TP change la route par défaut de la machine pour indiquer PPP à la place. ex :
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
Or en effectuant cette opération le système doit aussi ajouter une route pour garantir le lien vers le serveur VPN ex :
194.57.91.250 172.21.7.254 255.255.255.255 UGH 0 0 0 eth1
dans cet exemple le serveur VPN est 194.57.91.250 et la passerelle par défaut 172.21.7.254 sur l’interface eth1.

Si cette route est absente le lien entre le client et le serveur est immédiatement mis en défaut et la connexion se coupe au bout de quelques minutes => aucun échange avec quiconque n’est possible sans cette route.

Solution : relancer ipsec. Cette opération doit être également effectuée après chaque changement (up/down) d’interface.

LINUX : L2TP contre XL2TP

vendredi, mai 2nd, 2008

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.

Problème linux : Fedora Core 7, 8, 9 et PPP/L2TP

jeudi, avril 10th, 2008

La version de base il faut recompiler les sources de PPP (cf CRI XXXXXXXXXXXXXXXXX) car la version 2.4.2 (FC 7, 8) et la version 2.4.4-rel6 (FC 9) ne possède pas l’option replacedefaultroute nécessaire dans la configuration L2TP/PPP

VPN : encapsulation des informations

jeudi, avril 10th, 2008

sur le shéma ci-dessous, nous voyons comment IPSEC encapsule les données utilisateurs. Dans le mode transport et le mode tunnel.
encapsulation ipsec mode transport et tunnel

sur ce nouveau shéma, nous voyons les différentes étapes d’encapsulation lorsqu’on utilise L2TP en mode tunnel
ipsec et encapsulation l2tp

enfin sur ce troisième shéma, nous décrivons l’encapsulation d’une connexion l2tp à travers du nat
ipsec avec l2tp et du nat-t

PPPD + password

mercredi, avril 9th, 2008

en utilisant l’une des dernières versions de XL2TPD, il n’est plus nécessaire de placer le mot de passe dans le fichier /etc/ppp/pap-secrets :
#user2@lifc-edu 194.57.88.62 user2

il suffit de faire appel au module passwordfd.so dans /etc/ppp/options.l2tpd.client :
plugin passwordfd.so
user user2@lifc-edu
...

et de créer la connexion L2TP avec :
echo "c amande passwordfd user2" > /var/run/xl2tpd/l2tp-control