Documentation : Windows, MacOS, Linux

septembre 25th, 2008

La documentation windows a été validée pour XP et VISTA
config_windows-xp-20081020
config_windows-vista-20081020

La documentation MACOS a été validée pour TIGER et LEOPARD
config_macos-20081020

La documentation Linux a été validée pour DEBIAN 4.0, UBUNTU 7.10
config_linux-20081127

Références utiles :
site du CRI
site du VPN
– pour linux le site de Jacco de Leeuw

problème windows : impossible de trouver un certificat valide

septembre 3rd, 2008

Si l’erreur à la connexion VPN est : “Impossible de trouver un certificat valide”, vous devez suivre les instructions suivantes :
– enlever tous les certificats de la machine
– enlever les autorités de certification
– remettre le certificat que l’on vous a donné (VPN UFC)
– remettre les autorités de certification (normalement celui du VPN UFC est dans le certificat délivré => automatique)

Re-essayez une connexion VPN

Problème windows : erreur 691

août 28th, 2008

L’erreur 691 de windows indique que vous vous êtes trompé dans le login (user ou realm) ou de mot de passe :
Mon Aug 01 14:08:10 2008 : Auth: Login incorrect: [user@realm] (from client vpnX port 0 cli aaa.bbb.ccc.ddd)

VPN sous Linux à travers la solution UCOPIA (accès WIFI)

juillet 9th, 2008

Votre portable est sous linux et vous voulez effectuer une connexion VPN sur un serveur de l’UFC.

Or votre accès réseau passe par du WiIFi managé par une solution de contrôle de type UCOPIA.

Le principe d’UCOPIA est simple :vous vous connectez au SSID WiFi que l’on vous a fourni puis vous ouvrez votre navigateur et un portail captif se présente à vous à la place de la page que vous vouliez voir afficher. Vous entrez alors votre login/password et vous conservez une session active tant que la fenêtre de connexion UCOPIA reste ouverte. Dès la fermeture de la page UCOPIA vous perdez immédiatement le lien réseau.

Vous avez donc modifié votre /etc/ipsec.conf (avec la gateway que vous voyez [route -n]) :
leftnexthop=192.168.138.10

Premier problème : le fichier hosts
Malheureusement dès que vous lancez le VPN, vous perdez le lien réseau. Cela vient du fait qu’une fois le lien VPN monté votre DNS devient celui de l’UFC.
Or vous avez besoin (votre navigateur) de connaître l’ip de https://controller.ucopia.mobile/secure/index.php?blablabla
Pour corriger ce problème il suffit de déclarer le host controller.ucopia.mobile dans le fichier /etc/hosts

Deuxième problème : le proxy
Si vous activez le proxy par “Adresse de configuration automatique du proxy” (proxy.pac) vous perdez le lien presque aussitôt. Pour éviter cela il suffit de cliquer sur “Configuration manuelle du proxy” (mettre proxy-www.univ-fcomte.fr 3128) et surtout d’ajouter dans “Pas de proxy pour :” le nom controller.ucopia.mobile.

Dès que cela est fait, vous n’aurez plus de problème pour faire fonctionner votre connexion VPN.

liste des serveurs VPN et des REALMS

juillet 4th, 2008

VPN1 : Besançon 194.57.91.250, realm @ufc @lifc-lab @lifc-edu, @femto, @cri, @admin-bu et @admin-presidence.
VPN2 : Montbéliard 194.57.89.97, realm @ufc
VPN3 : Belfort 194.57.89.105, realm @ufc et @iutbm (à venir @lifc-lab)

Problème serveur : patch freeradius pour prise en compte du retour des proxies

juin 13th, 2008

Lors de l’utilisation d’un proxy par freeradius celui-ci, et quelle que soit la réponse du proxy, retourne toujours “OK” dans l’authentification. Ce problème a été solutionné par Jean-Michel Caricand qui a proposé un patch pour freeradius :

*** freeradius-1.1.3/src/main/radiusd.c Tue May 16 18:26:07 2006
--- /root/FREERADIUS/freeradius-1.1.3/src/main/radiusd.c        Sat Jan 26
11:04:06 2008
***************
*** 1585,1590 ****
--- 1585,1595 ----
        int rcode;
        rcode = proxy_receive(request);
        switch (rcode) {
+               case RLM_MODULE_REJECT:
+                       DEBUG2("Request %d rejected in proxy_receive.", request->number);
+                       request_reject(request);
+                       goto finished_request;
+                       break;
                 default:  /* Don't Do Anything */
                         break;
                 case RLM_MODULE_FAIL:

Problème serveur : récupération sur radius de l’IP de l’utilisateur

juin 13th, 2008

L’architecture du service VPN (station de travail -> VPN1/2/3/… -> RADIUS -> LDAP/RADIUS/… ) pose le problème suivant : le client RADIUS est le serveur VPN. De ce fait, RADIUS reçoit par défaut  l’adresse IP du NAS (machine VPN) alors qu’il serait intéressant d’obtenir également l’adresse IP du client réel, c’est-à-dire, la station de travail.

Sur le serveur VPN, le démon XL2TP lance le service PPP qui permet à l’utilisateur de transmettre des informations, notamment login/mot de passe. Le service PPP, inclut dans ses sources une partie RADIUSCLIENT (les binaires radiusclient1 que l’on charge sur le serveur VPN sont donc inutiles) qui adresse au serveur RADIUS via le protocole RADIUS les informations reçues par le serveur VPN.

Or nous avons besoin pour certaines applications du VPN de connaître (reconnaître) l’adresse IP de l’utilisateur (client final à ne pas confondre avec le client du serveur RADIUS) pour l’autoriser ou non à établir une connexion.
Or les arguments transmis par le VPN au serveur RADIUS sont les suivants :

Service-Type = Framed-User
Framed-Protocol = PPP
User-Name = "utilisateur@realm"
User-Password = "mot_de_passe"
NAS-IP-Address = IP_serveur_VPN
NAS-Port = 1

Le serveur RADIUS n’a donc pas d’information sur l’IP de l’utilisateur.

Jean-Michel Caricand a créé et appliqué un patch de quelques lignes pour transmettre cette information.
En effet, dans le fonctionnement de XL2TP (L2TP) sur le serveur VPN, nous pouvons transmettre des attributs statiques à l’aide de l’argument “ipparam”. Si cet argument est transmis, l’attribut qui suit est également transmis. On retrouve cela dans les fichiers de configuration avec le plus souvent une chaîne de caractères (par exemple pour éviter les récursions sur L2TP).
Notre idée est simple : introduire après l’argument ipparam l’adresse IP de l’utilisateur.
cela nous donne le patch :

--- xl2tpd-1.1.12.orig/control.c        2007-10-20 06:22:55.000000000 +0200
+++ xl2tpd-1.1.12/control.c     2008-06-12 15:01:16.000000000 +0200
@@ -954,6 +954,14 @@ int control_finish (struct tunnel *t, st
}
if (c->lns->debug)
po = add_opt (po, "debug");
+
+        po = add_opt (po, "ipparam");
+        po = add_opt (po, "%s", IPADDY (t->peer.sin_addr));
+
+        l2tp_log (LOG_DEBUG,
+             "Use ipparam option with %s value\n",
+             IPADDY (t->peer.sin_addr));
+
if (c->lns->pppoptfile[0])
{
po = add_opt (po, "file");

maintenant, nous avons bien une information supplémentaire très facile à traiter :

Service-Type = Framed-User
Framed-Protocol = PPP
User-Name = "utilisateur@realm"
User-Password = "motdepasse"
Calling-Station-Id = "IP_utilisateur"
NAS-IP-Address = IP_serveur_VPN
NAS-Port = 1

RADIUS : NAS-IP-Address et fichier /etc/hosts

mai 29th, 2008

Si votre fichier /etc/hosts contient
10.0.0.1 vpn3.univ-fcomte.fr vpn3

et que l’IP véritable de vpn3 soit 194.57.89.97

et que RADIUS est bien configuré pour 194.57.89.97

La requête RADIUS venant de vpn” sera bien accepter, mais il y aura un problème d’authentification si on vérifie le NAS-IP-address

paquet recu par le serveur RADIUS

rad_recv: Access-Request packet from host 194.57.89.105:32779, id=171, length=76
Service-Type = Framed-User
Framed-Protocol = PPP
User-Name = "test@ufc"
User-Password = "monpassword"
NAS-IP-Address = 10.0.0.1
NAS-Port = 0

au lieu de :

rad_recv: Access-Request packet from host 194.57.89.105:32779, id=171, length=76
Service-Type = Framed-User
Framed-Protocol = PPP
User-Name = "test@ufc"
User-Password = "monpassword"
NAS-IP-Address = 194.57.89.105
NAS-Port = 0

Utilisation du FTP depuis un accès VPN

mai 27th, 2008

Lors d’un accès VPN, il vous est attribué une adresse IP privée. Ce type d’adresse vous interdit un accès direct à Internet. Vous devez utiliser ce qu’on appelle un serveur mandataire (serveur proxy) pour pouvoir “atteindre” un service réseau situé en dehors du réseau universitaire. L’utilisation du FTP pour récupérer ou déposer des ressources nécessite donc un paramètrage de votre client FTP. Les informations utiles sont disponibles à cette adresse : Les proxys de l’Université de Franche-Comté

Problème Linux : route vers le serveur VPN absente

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.