Le vpn ne fonctionne derrière un NAT (même adresse ip de sortie) que pour la première personne connectée.
Archive for the ‘Informations utilisateurs’ Category
Problèmes NAT
vendredi, avril 23rd, 2010Problème windows : erreur d’authentification L2TP
lundi, novembre 23rd, 2009Si 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.
windows VISTA : erreur 789 ou 835
mercredi, octobre 21st, 2009cette 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
Windows seven
mercredi, juin 24th, 2009Pour 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.
Problème Windows : nom ou IP du serveur VPN ?
mardi, mai 19th, 2009il 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 ».
Linux : outils
mardi, avril 28th, 2009Dans 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 :
dhclient
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
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.
Problème Linux : certificat non reconnu
jeudi, mars 19th, 2009Un 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)
Problème MacOS Léopard
mercredi, novembre 12th, 2008Sous Léopard, si vous modifier la configuration du VPN après l’avoir valider une première fois, vous aurez sans doute un au lancement un fenêtre qui s’affiche avec le message « pppd wants to connect to vpn1.univ-fcomte.fr on udp port 1701« . Si vous cliquez sur le bouton Allow, une boîte apparaît avec le message « Connexion à Internet : le secret partagé IPsec est manquant » alors que vous n’avez pas configuré le VPN avec une clef partagé mais bien avec un échange de certificat.
Ce problème est un bug de l’OS de Léopard.
Pour remettre en ordre le VPN, il faut
– détruire la configuration du VPN
– détruire la configuration du WIFI (Airport)
– recréer la configuration Airport
– recréer la configuration VPN
Attention, lors de cette dernière étape, il faut créer une nouvelle connexion VPN (ufc-vpn par exemple) et ne pas utiliser la connexion « defaut ». Prendre soin de configurer tous les éléments, y compris « route par défaut par le VPN« .
Une fois fait, ne toucher plus à cette configuration, vous risquez de devoir tout recommencer dans le cas contraire.







Windows : script de modification de la base de registre
mercredi, novembre 5th, 2008Comme nous le conseillons ici ou là, nous vous laissons en téléchargement le petit script qui modifie la base de registre pour VISTA : patch-vpn-ufc-vista.reg
Linux : script de connexion déconnexion
mercredi, novembre 5th, 2008Avec la contribution de certains de nos collègues, nous publions quelques scripts pour Linux permettant de gérer la connexion et la déconnexion automatique au serveur VPN.
Jean-Michel Carricand nous à fait un script très simple de connexion :
#! /bin/bash
function usage() {
echo "Usage: $0 {start|stop|restart} connection_name password"
exit 1
}
CONN="$2"
PASS="$3"
DEFAULTROUTE=`route -n | grep '^0.0.0.0' | tr -s ' ' ' ' | cut -d' ' -f2`
case "$1" in
start)
[ -z "$2" -o -z "$3" ] && usage
$0 stop
/etc/init.d/ipsec start; sleep 2
ipsec auto --up ufc-vpn; sleep 2
route add 194.57.91.250 gw $DEFAULTROUTE
/etc/init.d/xl2tpd start; sleep 2
echo "c $CONN passwordfd $PASS" > /var/run/xl2tpd/l2tp-control
;;
stop)
echo "d $CONN" > /var/run/xl2tpd/l2tp-control; sleep 2
/etc/init.d/xl2tpd stop
ipsec auto --down ufc-vpn
/etc/init.d/ipsec stop
route del 194.57.91.250 gw $DEFAULTROUTE
;;
restart)
$0 stop
$0 start
;;
*)
usage
;;
esac
Jérôme Rabouille (UFR-STGI) :
#!/bin/bash
# Ecrit par Jérôme Rabouille / UFR STGI
# Montage du VPN UFC sous linux avec IPSEC(openswan) / xl2tpd
# Testé sous Ubuntu Hardy
VPN_NAME="ufc-vpn" #nom du vpn dans /etc/ipsec/conf
MACHINE_NAME_XL2TPD=ma_machine #nom de la machine dans /etc/xl2tpd/xl2tpd.conf
L2TPD_SCRIPT=/etc/init.d/xl2tpd
L2TPD_PIPE=/var/run/xl2tpd/l2tp-control
IPSEC_SCRIPT=/etc/init.d/ipsec
IPSEC_COMMAND=/usr/sbin/ipsec
if [ "$UID" = "0" ]; then
case "$1" in
start)
echo "Saisir le mot de passe(ENT): "
read -s PASSWORD
$IPSEC_SCRIPT start > /dev/null
$L2TPD_SCRIPT start > /dev/null
sleep 2
$IPSEC_COMMAND auto --up $VPN_NAME > /dev/null
echo "c $MACHINE_NAME_XL2TPD passwordfd $PASSWORD" > $L2TPD_PIPE
sleep 3
ppp_ip="`/sbin/ifconfig ppp0 | grep 'inet adr' | awk '{print $2}' | sed -e 's/.*://'`"
echo "IP LOCAL UFC:" $ppp_ip
;;
stop)
echo "d $MACHINE_NAME_XL2TPD" > $L2TPD_PIPE
$IPSEC_COMMAND auto --down $VPN_NAME > /dev/null
sleep 2
$L2TPD_SCRIPT stop > /dev/null
$IPSEC_SCRIPT stop > /dev/null
;;
*)
echo "usage: "$0 "[start|stop]"
echo "Montage du VPN de l'UFC"
;;
esac
else
echo "ERREUR: Vous devez être super utilisateur!"
exit 1
fi
exit 0
Cédric Clerget (FEMTO-ST) :
Alors j’ai noté quelques problèmes sur mon PC du boulot et mon PC perso. Les deux PC tournent avec une Debian ETCH 64 bits. La connexion se fait sans problème, petit hic, si je souhaite utiliser les DNS FEMTO-ST lorsque je me connecte au realm femto-st je dois éditer /etc/resolv.conf afin d’y ajouter :
search femto-st.fr
nameserver 172.20.208.80
C’est ce que fait le script une fois connecté (script intrusif, n’hésitez pas a sauvegarder /etc/l2tp et /etc/ipsec avant).
#! /bin/sh
# A changer selon le lieu d'ou vous vous connectez
PASSERELLE="192.168.1.254"
# A changer selon votre localisation géographique
SERVEUR_VPN="194.57.91.250"
# chemin du certificat utilisateur
USER_CERT="/etc/ipsec.d/certs/mycert.pem"
# La connexion au VPN impose l'utilisation unique du réseau de l'UFC,
# et par conséquent l'utilisation du proxy de l'UFC afin de pouvoir surfer.
# Si vous souhaitez utiliser votre connexion pour le surf ou autres choses
# tout en restant dans le réseau UFC, vous le pouvez en mettant la valeur
# du champs suivant à 1
DUALROUTE_ACTIVE=1
DUALROUTE_SCRIPT="/etc/ppp/ip-up.d/dualroute"
# Pour la restauration des DNS de votre connexion internet, car la restauration
# ne fonctionne pas avec pppd (bug ? feature ?)
RESOLV_BACKUP="/etc/resolv.conf.pppd-backup"
# si vous désirez remplacer les DNS par défaut attribuer lors de la connexion, sinon commentez les 5 lignes suivantes
RESOLV_CONF=`
cat << RESOLV_CONF
search femto-st.fr
nameserver 172.20.208.80
RESOLV_CONF`
initialisation () {
# Demande de saisi de l'utilisateur et du mot de passe
echo -n "Utilisateur (ex : identifiant@realm) : "
read USER
echo -n "Mot de passe : "
read -s PASSWORD
echo ""
echo "Connexion en cours ..."
# génération du fichier /etc/ppp/ip-up.d/dualroute
DUALROUTE=`
cat << DUALROUTE
#!/bin/sh
route add -net 172.20.0.0 netmask 255.255.0.0 dev \\$1
DUALROUTE`
# génération du fichier /etc/ipsec.conf
IPSEC_CONF=`
cat << IPSEC_CONF
version 2
config setup
uniqueids=yes
nhelpers=0
nat_traversal=yes
conn %default
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert
type=transport
keyingtries=1
include /etc/ipsec.d/examples/no_oe.conf
conn ufc-vpn
rightprotoport=17/1701
leftprotoport=17/1701
keyexchange=ike
pfs=no
auto=add
left=%defaultroute
leftcert=$USER_CERT
leftrsasigkey=%cert
right=$SERVEUR_VPN
rightrsasigkey=%cert
rightca=%same
leftnexthop=$PASSERELLE
IPSEC_CONF`
# génération du fichier /etc/xl2tpd/xl2tpd.conf
XL2TP_CONF=`
cat << XL2TP_CONF
[global]
port = 1701
access control = no
[lac machine_lambda]
lns = $SERVEUR_VPN
redial = yes
redial timeout = 10
max redials = 10
length bit = yes
refuse authentication = yes
refuse chap = yes
require pap = yes
name = perso
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client
XL2TP_CONF`
# génération du fichier /etc/ppp/options.l2tpd.client
if [ $DUALROUTE_ACTIVE == 0 ]; then
REPLACEROUTE_OPTION="replacedefaultroute"
else
REPLACEROUTE_OPTION="noreplacedefaultroute"
fi
OPTIONS_L2TP=`
cat << OPTIONS_L2TP
defaultroute
$REPLACEROUTE_OPTION
debug
lock
user $USER
noipdefault
usepeerdns
noauth
lcp-echo-interval 20
lcp-echo-failure 10
noaccomp
OPTIONS_L2TP`
}
case "$1" in
start)
initialisation
echo -e "$IPSEC_CONF" > /etc/ipsec.conf
echo -e "$XL2TP_CONF" > /etc/xl2tpd/xl2tpd.conf
echo -e "$OPTIONS_L2TP" > /etc/ppp/options.l2tpd.client
if [[ ! -e $DUALROUTE_SCRIPT && $DUALROUTE_ACTIVE == 1 ]]; then
echo -e "$DUALROUTE" > $DUALROUTE_SCRIPT
chmod +x $DUALROUTE_SCRIPT
fi
/etc/init.d/ipsec start > /dev/null && /etc/init.d/xl2tpd start > /dev/null
sleep 3
if [ ! -z "$PASSWORD" ]; then
ipsec auto --up ufc-vpn > /dev/null && echo "c machine_lambda passwordfd $PASSWORD" > /var/run/xl2tpd/l2tp-control
fi
if [ ! -z "$RESOLV_CONF" ]; then
sleep 6
echo -e "$RESOLV_CONF" > /etc/resolv.conf
fi
;;
stop)
echo -e "Déconnexion en cours ..."
echo "d machine_lambda" > /var/run/xl2tpd/l2tp-control && ipsec auto --down ufc-vpn > /dev/null
/etc/init.d/ipsec stop > /dev/null && /etc/init.d/xl2tpd stop > /dev/null
# restauration du fichier /etc/resolv.conf écraser par la connexion VPN
if [ -e "$RESOLV_BACKUP" ]; then
mv $RESOLV_BACKUP /etc/resolv.conf
fi
# restauration de la route par défaut afin de pouvoir utiliser de nouveau sa connexion internet
if [ $DUALROUTE_ACTIVE == 0 ]; then
route add default gw $PASSERELLE
fi
rm -f $DUALROUTE_SCRIPT
;;
*)
echo "Usage: connexion-vpn {start|stop}" >&2
exit 3
;;
esac
: