Si 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).
Archive for the ‘problèmes utilisateurs’ Category
Problème d’authentification
mardi, mai 6th, 2008Problè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.
Problème linux : log de connexion
mercredi, avril 9th, 2008Les logs liés à une connexion VPN se trouvent dans /var/log/auth.log, /var/log/syslog et /var/log/messages.
Au lancement de la connexion IPsec (on voit ici que la connexion est à travers du nat) vous devez avoir des logs similaires à ceux-ci dans /var/log/auth.log (ou /var/log/messages):
#49: initiating Main Mode
#49: ignoring unknown Vendor ID payload [4f456c4c4f5d5264574e5244]
#49: received Vendor ID payload [Dead Peer Detection]
#49: received Vendor ID payload [RFC 3947] method set to=110
#49: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
#49: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
#49: STATE_MAIN_I2: sent MI2, expecting MR2
#49: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed
#49: I am sending my cert
#49: I am sending a certificate request
#49: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
#49: STATE_MAIN_I3: sent MI3, expecting MR3
#49: Main mode peer ID is ID_IPV4_ADDR: '194.57.91.251'
#49: no crl from issuer "C=FR, ST=Franche-Comte, L=Besancon, O=UFC, OU=CRI, CN=CA-vpn, E=vpn-master@univ-fcomte.fr" found (strict=no)
#49: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
#49: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
#50: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+UP {using isakmp#49}
#50: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
#50: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x2e19c272 <0x37ba5dd5 xfrm=AES_0-HMAC_SHA1 NATD=194.57.91.251:4500 DPD=none}
Si vous n’avez pas de log de connexion IPsec, il faut vérifier votre fichier ipsec.conf, car il doit contenir des erreurs de syntaxe.
lors de la connexion (x)l2tp vous devriez avoir dans /var/log/syslog :
: pppd 2.4.4 started by root, uid 0
: Using interface ppp0
: Connect: ppp0 <--> /dev/pts/2
: Remote message: user2@lifc-edu connecte a lifc-edu^J
: PAP authentication succeeded
: replacing old default route to eth0 [192.168.1.254]
: local IP address 172.20.128.37
: remote IP address 192.168.255.201
: primary DNS address 194.57.91.200
: secondary DNS address 194.57.91.200
votre nouvelle adresse IP est précisée ici : : local IP address 172.20.128.37
Si vous n’avez pas de log (x)l2tp, vous pouvez lancer l2tpd en mode debug avec la commande suivante, en utilisateur root :
/etc/init.d/xl2tpd stop ou /etc/init.d/l2tpd stop
xl2tpd -D -c /etc/xl2tpd/xl2tpd.conf ou l2tpd -D -c /etc/l2tpd/l2tpd.conf
Ensuite effetcuez dans une autre fenêtre root le montage du lien PPP
echo "c user2" > /var/run/xl2tpd/l2tp-control ou echo "c user2" > /var/run/l2tp-control
Le résultat des logs dans la première fenêtre doit vous apporter de l’aide pour corriger votre problème.
Si cela persiste n’hésitez pas à contacter votre correspondant réseau ou vpn-master@univ-fcomte.fr
Problème linux : je perds ma route par défaut en déconnectant le VPN
mercredi, avril 9th, 2008Lorsque vous effectuez la connexion VPN, les routes sur votre ordinateur ressemblent à cela :
cri-29:~# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.255.201 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
194.57.91.251 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
Lors de la déconnexion, il ne vous reste que :
cri-29:~# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.255.201 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
194.57.91.251 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
La route par défaut a disparu et vous ne pouvez plus aller sur Internet.
Pour résoudre ce problème, vous pouvez taper manuellement (sous l’utilisateur root) :
route add default gw 192.168.1.254
ou utiliser les scripts suivants :
/etc/ppp/ip-pre-up
#!/bin/sh
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin
export PATH
PPP_IFACE="$1"
PPP_TTY="$2"
PPP_SPEED="$3"
PPP_LOCAL="$4"
PPP_REMOTE="$5"
PPP_IPPARAM="$6"
export PPP_IFACE PPP_TTY PPP_SPEED PPP_LOCAL PPP_REMOTE PPP_IPPARAM
PPP_TTYNAME=`/usr/bin/basename "$2"`
export PPP_TTYNAME
run-parts /etc/ppp/ip-pre-up.d \
--arg="$1" --arg="$2" --arg="$3" --arg="$4" --arg="$5" --arg="$6"
EOF
etc/ppp/ip-pre-up.d/save-defaultroute
#! /bin/bash
GW=$(route -n | grep '^0.0.0.0' | tr -s ' ' ' ' | cut -d' ' -f2)
[ -n "$GW" ] && echo $GW > /tmp/$PPP_IFACE.defaultroute
exit 0;
et etc/ppp/ip-down.d/restore-defaultroute
#! /bin/sh -e
[ -f /tmp/$PPP_IFACE.defaultroute ] || exit 0
GW=$(cat /tmp/$PPP_IFACE.defaultroute)
route add default gw $GW
exit 0;
Si vous utilisez xl2tpd, un autre problème se pose pour vous. xl2tpd ne fait pas appel aux scripts de déconnexion de la session PPP. Il faut donc patcher xl2tpd en utilisant le repository du LIFC par exemple.