Archive for the ‘informations techniques’ Category

Correction de la déconnexion des clients MAC OSX

mercredi, janvier 28th, 2015

Les usagers du VPN avec ddes clients Mac OSX peuvent éprouver des difficultées suite à des déconnexions.
Ces déconnexions, si elles ne sont pas dûes à d’autre causes, sont interne au système OSX.
Cela est noté comme bug depuis Mac OSX 10.9.1. Apple refuse de le corriger.
Il existe un fichier dans les Mac OSX qui spécifie un timeout au bout de 3600s.

Vous trouverez des fichiers *.conf dans /var/run/racoon/.
L’un d’eux annoncera lifetime time 3600 sec

pour corriger le problème, il suffit de suivre le post de Simon Heimlicher

VPN et accès Internet

mercredi, décembre 17th, 2014

Jusqu’à présent lorsque vous êtes connectés en VPN sur l’UFC, vous ne pouvez pas naviguer en même temps sur Internet sans configurer le proxy.
Du coup certains services sont difficilement accessible (Visio/SSH/…).
Nous avons mis en place une solution pour que les usagers du VPN dans le realm @ufc puisse avoir accès à l’extérieur sans pour autant configurer un serveur mandataire.
Il s’agit du serveur NAT qui est pour le moment en phase de tests.
Si vous avez un retour à ce sujet n’hésitez pas à contacter vpn-master at univ-fcomte.fr

windows + WIFI SSID ufc-vpn + problème MTU

mardi, novembre 25th, 2014

Sous windows 7 en étant sur le Wifi (ssid ufc-vpn), il est possible d’avoir un souci de MTU.
C’est Gérard Asensio qui nous remonte un problème d’accès à un serveur de jeton et sa solution :

netsh interface ipv4>show interface

Idx Mét MTU État Nom
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
14 30 1500 connected Connexion réseau sans fil
17 5 1500 disconnected Connexion réseau sans fil 2 <-- SSID ufc-vpn 13 5 1500 disconnected Connexion au réseau local 19 30 1300 connected Connexion au réseau local* 4 <---- connexion vpn

Pour que le jeton de licence passe, il faut un mtu de 1300 sur les interfaces physiques utilisables par le VPN ( wifi ou filaire ) :

netsh interface ipv4>set subinterface "Connexion réseau sans fil" mtu=1300 store=persistent
Ok.

netsh interface ipv4>set subinterface "Connexion au réseau local" mtu=1300 store=persistent
Ok.

netsh interface ipv4>show interface

Idx Mét MTU État Nom
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
14 30 1300 connected Connexion réseau sans fil
17 5 1500 disconnected Connexion réseau sans fil 2 <-- SSID ufc-vpn 13 5 1300 disconnected Connexion au réseau local 19 30 1380 connected Connexion au réseau local* 4 <---- connexion vpn

Remettre un interface en mtu 1500 :

netsh interface ipv4>set subinterface "Connexion réseau sans fil 2" mtu=1500 store=persistent
Ok.

netsh interface ipv4>set subinterface "Connexion au réseau local* 4" mtu=1500 store=persistent
Ok.

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

mardi, 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}

GNU Linux Magazine France

mardi, 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).

Linux : outils

mardi, 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 :

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 serveur : les utilisateurs ont un problème de routage asymétrique

mardi, janvier 6th, 2009

Si les utilisateurs ont un problème de route asymétrique entre l’envoie d’un paquet et sa réception ce qui entraîne une rupture de connexion de la part du FireWall, il faut commencer par regarder la configuration des interfaces car c’est à cet endroit que nous effectuons un routage.
Pour rappel, le FireWall divise en quatre grandes classes l’ensemble des classe IP de l’UFC (chacune à sa VRF).
Sur le FW, plusieurs de ces classes sont réunis et il faut faire extrêmement attention à ne pas créer sur la machine VPN un routage inter-classe qui entraînera pour le moins un dysfonctionnement pour l’utilisateur (au pire un dysfonctionnement d’une partie du réseau de l’UFC).
Avec le code suivant :
auto eth0.168
iface eth0.168 inet static
address 172.20.16.220
netmask 255.255.255.0
network 172.20.16.0
broadcast 172.20.16.255
up ip route add default via 172.20.16.254 dev eth0.168 table admin.pres
up ip rule add fwmark 18 table admin.pres
down ip rule del fwmark 18
down ip route del table admin.pres

Nous avons deux règles très importantes :
la première :
up ip route add default via 172.20.16.254 dev eth0.168 table admin.pres
qui implique une route par défaut pour tous les utilisateurs VPN du tag 18 (admin.pres).
la seconde :
up ip rule add fwmark 18 table admin.pres
car c’est par elle que l’on affecte au client le tag 18.

Si le code dans le fichier /etc/network/interfaces ressemble à
up ip route add default via 172.20.16.254 dev eth0.168 table admin.pres
ip up rule add fwmark 18 table admin.pres

Tous les clients de ce réseaux ne seront pas affecté au tag 18 et donc tout leur trafic transitera par l’interface de routage par défaut de la machine qui est sans aucun doute dans une VRF distincte et donc entraînera un dysfonctionnement des connexion de ces clients vers l’extérieur de leur réseau de connexion.

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

vendredi, 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

vendredi, 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

jeudi, 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