si votre connexion filaire fonctionne parfaitement bien et qu’en wifi vous n’arrivez pas à joindre le serveur VPN (code erreur windows 698…), il est fort possible que vous ayez un client VPN type « NETGEAR VPN CLIENT » déjà configuré sur votre machine. Celui-ci n’empêche pas la connexion filaire met prend la main sur les connexions WIFI
Problème Windows : connexion filaire OK connexion WIFI NOK
mai 21st, 2008Surveillance des services sur les serveurs VPN
mai 20th, 2008Pour effectuer la surveillance des serveurs VPN (une fois opérationnel, ces serveurs seront des points d’entrée critique), nous avons décider d’utiliser NAGIOS et l’addon NRPE.
Sur les serveurs VPN, lancer apt-get update && apt-get install nagios-plugins nagios-nrpe-server
et apt-get install nagios-plugins-lifc.
Modifier le fichier /etc/nagios/nrpe.cfg
allowed_hosts=127.0.0.1,<adresse_serveur_nagios>
#command[check_disk1]=/usr/lib/nagios/plugins/check_disk -w 20 -c 10 -p /dev/hda1
#command[check_disk2]=/usr/lib/nagios/plugins/check_disk -w 20 -c 10 -p /dev/hdb1
command[check_disk1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /
command[check_ppp_connect]=/usr/lib/nagios/plugins/check_ppp_connect -w 20 -c 30
command[check_xl2tpd]=/usr/lib/nagios/plugins/check_xl2tpd
relancer le serveur NRPE : /etc/init.d/nagios-nrpe-server restart
modification non obligatoire dans le fichier /etc/services
nrpe 5666/tcp # Nagios NRPE
On vérifie que le service nrpe tourne correctement :
netstat -at | grep nrpe
Tester la connexion depuis le serveur Nagios : /usr/local/nagios/libexec/check_nrpe -H <adresse_client_nagios> -c check_users
sur le serveur nagios
définition d’un template service :
define service{
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 5
retry_check_interval 2
notification_interval 120
contact_groups admins-serveurs-vpn
notification_options w,u,c,r
notification_interval 120
notification_period 24x7
name services-vpn
active_checks_enabled 1 ; Active service checks are enabled
passive_checks_enabled 1 ; Passive service checks are enabled/accepted
parallelize_check 1 ; Active service checks should be parallelized (disabling this can lead to major performance problems)
obsess_over_service 1 ; We should obsess over this service (if necessary)
check_freshness 0 ; Default is to NOT check service 'freshness'
notifications_enabled 1 ; Service notifications are enabled
event_handler_enabled 1 ; Service event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
failure_prediction_enabled 1 ; Failure prediction is enabled
process_perf_data 1 ; Process performance data
retain_status_information 1 ; Retain status information across program restarts
retain_nonstatus_information 1 ; Retain non-status information across program restarts
register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
}
définition d’un template host :
define host{
name linux-box ; The name of this host template
use generic-host ; This template inherits other values from the generic-host template
check_period 24x7 ; By default, Linux hosts are checked round the clock
check_interval 5
# retry_interval 1
max_check_attempts 10
check_command check-host-alive
notification_period 24x7
notification_interval 120
notification_options d,r
contact_groups admins-serveurs-vpn
register 0
}
création des hotes :
define host{
host_name Besancon_Bouloie_metro-C_test-vpn ; The name we're giving to this server
alias test-vpn ; A longer name for the server
address 194.57.91.251 ; IP address of the server
use linux-box ; Inherit default values from a template
}
...
création des services :
define service{
use services-vpn
host_name Besancon_Bouloie_metro-C_test-vpn
service_description CPU Load
check_command check_nrpe!check_load
}
...
création du hostgroup :
define hostgroup{
hostgroup_name TEST_Equipements
alias TEST
members Besancon_Bouloie_metro-C_test-vpn, Besancon_Bouloie_metro-C_vpn1, Besancon_Bouloie_metro-C_vpn2
}
Configuration serveur : connexion client XP/VISTA
mai 15th, 2008Depuis la sortie de VISTA SP1, la connexion IPSEC ne s’effectue plus correctement car il manque une commande (forceencaps=yes) dans la configuration des connexions pour les clients XP/VISTA.
Si, dans la configuration du serveur nous modifions légèrement la connexion pour les clients XP/VISTA en ajoutant :
conn vpn-l2tp-XP
# force l'encapsulation en UDP
forceencaps=yes
alors la connexion d’un VISTA SP1 fonctionne.
De fait, il faudra faire attention en cas de problème de connexion à bien ajouter dans REGEDIT la valeur (pour VISTA) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
(pour XP) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec valeur DWORD AssumeUDPEncapsulationContextOnSendRule à 2 comme cela est spécifié dans l’article Problème VISTA/XP SP2 : modification de la base de registre
Pour le moment nous avons deux choix au niveau du serveur :
– imposer la manipulation de regedit pour les clients XP et garder un type de connexion commune pour XP et VISTA
– régénérer des certificats pour les clients VISTA et créer une connexion spécifique pour VISTA et conserver la connexion XP actuelle.
Le choix sera déterminé semaine 21 suivant les essais faits avec XP SP2 et SP3 et VISTA sans SP1 et avec SP1. Pour le moment seuls les clients XP SP2 et VISTA sans SP1 peuvent utiliser les serveurs IPSEC.
Les résultats des tests démontrent que pour Windows XP SP1/SP2 et SP3 nous pouvons conserver la même configuration client et serveur => aucun changement à effectuer sur les postes clients XP ni de changement de certificat.
Pour Windows VISTA sans SP1 ou avec SP1, il faut mettre à jour la base de registre.
Problème WIFI SSID vpn-ufc : DNS / adresse IP
mai 15th, 2008Attention, lorsque vous configurez l’adresse du serveur VPN en utilisant le SSID vpn-ufc présent sur les bornes de l’Université de Franche-Comté, vous ne devez pas mettre le nom du serveur mais son adresse IP.
ex : 194.57.91.251 au lieu de test.vpn.univ-fcomte.fr
ex : 194.57.91.250 au lieu de vpn1.univ-fcomte.fr
En effet, ce SSID ufc-vpn n’a accès qu’aux serveurs VPN et donc n’a pas accès aux différents serveurs de nom (que ce soit ceux de l’UFC ou de votre provider).
Problème Windows : Zone Alarm
mai 13th, 2008Zone Alarm peut vous poser des soucis de connexion car établir un VPN est une action de connexion sur un site distant via un logiciel non enregistré par Zone Alarm.

Pour cela il suffit d’ajouter le serveur dans les machines autorisées pour une connexion (ajout d’une adresse IP) :

Le même problème surviendra pour les accès sur des réseaux intérieurs à l’UFC via le VPN :

il faudra encore une fois ajouter ce réseau à la liste des réseaux sécurisés :

IPSEC et taille du certificat serveur
mai 7th, 2008Le protocole IKE d’échange des certificats entre le serveur et le client ne supporte pas, de la part du serveur, une fragmentation des paquets contenant le certificat. Ainsi, avec une clef de certificat de taille 1024 bits, tout se passe bien, mais si l’on en crée une de 4096 bits, le serveur est incapable de négocier avec le client une connexion IPSEC.
Les serveurs VPN sont donc équipés de certificats avec des clefs de 1024 bits.
Problème d’authentification
mai 6th, 2008Si 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).
Problème VISTA/XP SP2 : modification de la base de registre
mai 5th, 2008George Ou a trouvé un problème sous VISTA (et sous XP service pack 2) lors de la connexion d’un client sur openswan à travers un NAT. Le problème empêche la connexion VPN IPSEC de s’établir.


L’article Configuration serveur : connexion client XP/VISTA donne des précisions importantes sur ce sujet.
Pour corriger cela (si vous avez lu l’article en lien, seul VISTA a besoin d’un changement de la base de registre) un article est paru chez microsoft.
En ce qui nous concerne, il faut ouvrir la base de registre, naviguer jusqu’à HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
(ou avec XP SP2 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec) et créer le DWORD (32-bit) AssumeUDPEncapsulationContextOnSendRule avec la valeur 2
Pour une prise en compte de la nouvelle base de registre, redémarrer Windows.
LINUX serveur : script
mai 2nd, 2008Un script spécifique lors de la création d’un lien PPPXX à été écrit pour éliminer dans IPTABLES (mangle) les restes des connexions mal fermé. Le problème est l’accumulation dans la tabe mangle de connexion lié au même PPP alors que la connexion en cours à besoin d’un ajout en cours pour sa propre connexion PPP.
Le script effectue donc une élimination de toutes les lignes dans mangle traitant du PPP en cours ; ensuite il y a ajout de la bonne ligne PPP dans la table mangle.
Le fichier se trouve dans : ip-pre-up.d/vpn-pre-connect