Windows : problème d’accès aux services une fois la connexion établie

mars 17th, 2020

Attention, ce post est un peu technique.

Sous Windows, lorsque vous établissez la connexion VPN, une connexion est établie entre votre matériel et le serveur VPN. Pour cela, il est créé sur votre matériel une nouvelle connexion réseau.

Malheureusement, malgré la connexion parfaitement établie, vous n’accéder pas au service voulu. En faisant un ping, vous arrivez à atteindre un certain nombre de services, mais globalement pas les services dont vous avez besoin (document partagé/apogee/harpege/cocktail/…).

Analyse

Vous pouvez la voir en ouvrant une console de commande (taper cmd dans la barre de texte en bas à gauche) et en tapant

netsh interface ip show config

Vous pouvez repérer la connexion de base (WIFI ou filaire) que vous avez utilisée pour vous connecter au VPN. Souvent une interface comme cela :

Configuration pour l'interface « Ethernet 3 »
DHCP activé : Non
Adresse IP : 192.168.1.6
Préfixe de sous-réseau : 192.168.1.0/24 (masque 255.255.255.0)
Passerelle par défaut : 192.168.1.254
Métrique de passerelle : 256
Métrique de l'interface : 25
Serveurs DNS configurés statiquement : 8.8.8.8
8.8.4.4
Enregistrer avec le suffixe : Aucun
Serveurs WINS configurés statiquement : Aucun

et la connexion VPN :

Configuration pour l'interface « Ethernet 8 »
DHCP activé: Oui
Adresse IP : 172.20.250.4
Préfixe de sous-réseau : 172.20.250.0/24 (masque 255.255.255.0)
Métrique de l'interface : 55
Serveurs DNS configurés via DHCP : Aucun
Enregistrer avec le suffixe : Principale uniquement
Serveurs WINS configurés via DHCP : Aucun

Ce qui nous intéresse ici, ce sont les deux valeurs de métrique
Configuration pour l’interface « Ethernet 3 »
Métrique de l’interface : 25
Configuration pour l’interface « Ethernet 8 »
Métrique de l’interface : 55

Pour que l’information transite bien par le VPN et pas par votre connexion de base, il faut que la valeur de la métrique de la connexion VPN ( « Ethernet 8 » ici) soit inférieure à celle de la connexion de base ( « Ethernet 3 » ).

Correction

Pour corriger cela, il suffit dans la fenêtre de commande de taper :

netsh int ip set interface interface=\"Ethernet 8\" metric=10

Ce qui va passer la métrique de la connexion VPN en deçà de celle de base et donc les connexions aux services que vous cherchez à atteindre passeront par le VPN.

Opérateurs et IPv6

août 26th, 2019

Chez certains opérateurs, la connexion réseau s’établit en IPv6.
Cela n’impacte pas votre navigation, mais comme le serveur VPN est en IPv4 seulement, vous ne pourrez pas vous connecter.

Donc si vous utilisez votre téléphone pour connecter votre portable informatique (plus le partage de connexion WIFI ou USB).

Il faut donc aller dans les paramètres du téléphone pour valider IPv4 uniquement et refaire la procédure de connexion VPN.

Problèmes Windows

février 12th, 2019

Deux types de problème ces derniers jours.

PROBLEME : la connexion SHREW s’établit, mais il semble que rien ne soit possible ensuite.
SOLUTION trouvée : désinstallation de SHREW, réinstallation SHREW et ré-importation du certificat.

PROBLEME : la connexion ne veut pas s’établir et passe en erreur (timeout)
SOLUTION :
– avec Kaspersky, vérifier si SHREW fait bien parti des logiciels autorisé ?
– avec certain anti-virus, il faut désinstaller l’anti-virus, rebooter la machine lancer la connexion VPN.
Si cela fonctionne, réinstaller l’anti-virus.

Problème d’importation de “.vpn” sous Linux depuis Zimbra (ou autre mailer)

octobre 4th, 2017

Si vous avez une erreur lors du lancement de la connexion VPN ou si SHREW vous demande une authentification du certificat, c’est que vous pouvez avoir l’erreur d’importation.

Sous Linux, nous retrouvons le répertoire “Téléchargement” qui est le plus souvent le répertoire par défaut de sauvegarde des pièces jointes des courriers électroniques.
Or votre certificat vous est envoyé par courrier électronique.
Si vous essayez d’importer depuis SHREW le “.vpn” qui se trouve dans le répertoire “Téléchargement“, celui-ci sera mal importé.
Cette erreur d’importation vient du logiciel SHREW qui gère mal les accents lors du choix du fichier à importer.

Il vous suffit de déplacer le “.vpn” dans votre répertoire principal et de réimporter le certificat.
Les erreurs ne devraient alors plus se reproduire.

Windows 10 et route par défaut

janvier 4th, 2017

Sous Windows 10 (suite à une mise à jour de l’OS) nous avons remarqué que le système conserve l’ancienne route par défaut lors de la mise en place de la connexion VPN via SHREW.

De fait votre système utilise la route par défaut classique (au lieu de la route qui mène au serveur VPN) pour la résolution de nom (entre autre).

Cela entraîne un dysfonctionnement lors de l’accès à des ressources privées de l’UFC.

Pour corriger cela, il faut :
– Cliquez sur démarrer > exécuter, tapez ”ncpa.cpl” et cliquez sur OK ;
– Faites un clic droit sur l’adaptateur réseau souhaité puis cliquez sur “Propriétés” ;
– Sélectionnez Propriétés Internet version 4 (TCP/IPv4) puis cliquez sur “Propriétés” ;
– Cliquez sur Avancé…
– Décochez “Métrique automatique” puis spécifiez ”100” sur la métrique de routage au niveau du champ “Métrique de l’interface”.

Votre VPN devrait maintenant être utilisé pour toutes les connexions réseau.

Pas de réseau

janvier 14th, 2016

Après la mise en route du VPN et de votre authentification, vous vous rendez compte que vous n’avez pas de réseau.
Même un ping sur votre passerelle (172.20.252.254 si vous êtes dans le realm @ufc) ne passe pas.
Pourtant le système VPN vous a bien donné une ip (172.20.252.xxx si vous êtes dans le realm @ufc).

C’est un souci qui se produit parfois suite à plusieurs déconnexions et reconnexions de votre client VPN (SHREW, sous MACOSX ce problème ne s’est pas posé en ces termes).
Ces déconnexions/connexions peuvent être volontaire ou non c’est-à-dire qu’il est possible qu’elles passent inaperçues.

Pour résoudre le souci, il faut :
– se déconnecter du VPN
– fermer la fenêtre de connexion VPN (SHREW)
– stopper le démon iked et ipsecd
* sous linux faire sudo iked
* sous window dans une fenêtre cmd
net stop ipsecd
net stop iked
net start iked
net start ipsecd

puis refaire les opérations de connexion :
– relancer le démon iked
– relancer la fenêtre de connexion VPN (SHREW)
– se connecter au VPN

Sinon vous avez aussi la possibilité de relancer votre poste de travail.

Erreur de librairie lors de l’installation de SHREW (Linux)

janvier 11th, 2016

Suite à une réinstallation et la découverte de ce bug, Ernest Chiarello nous indique la marche à suivre.

Dans les sources de ubuntu, il la version 2.2.1 de Shrew existe.

# dpkg --list | grep -i shrew
ii ike 2.2.1+dfsg-2ubuntu1 amd64 Shrew Soft VPN client - Daemon and libraries
ii ike-qtgui 2.2.1+dfsg-2ubuntu1 amd64 Shrew Soft VPN client - Connection manager

Si iked se lance sans souci, vous pouvez avoir un problème avec qikea

$ qikea &
[1] 3856
qikea: error while loading shared libraries: libss_ike.so.2.2.1: cannot open shared object file: No such file or directory

Effectivement on vérifie se manque par :

$ ldd `which qikea`
libss_ike.so.2.2.1 => not found
libss_idb.so.2.2.1 => not found
libss_ith.so.2.2.1 => not found
libss_log.so.2.2.1 => not found

Mais nous pouvons corriger en demandant à ldd de rajouter les librairies utilisées par iked, en créant un fichier /etc/ld.so.conf.d/iked.conf comme suggéré ici : http://comments.gmane.org/gmane.network.vpn.shrew.user/3195

# cat /etc/ld.so.conf.d/iked.conf
/usr/lib/x86_64-linux-gnu/ike

Il faut terminer en lançant :

# ldconfig

Enfin, il faut noter que l’interface graphique qikea est disponible dans l’environnement utilisateur. (internet->shrew).
il n’est donc pas nécessaire de la lancer depuis une console, à moins d’avoir besoin de debugguer.

Erreur : Shrew Soft VPN failed to attach to key daemon error

février 2nd, 2015

Cette erreur provient sans doute d’un service qui n’est pas activé
Il faut donc rechercher les services “ShrewSoft IKE Daemon” et “ShrewSoft IPSEC Daemon”, vérifier qu’ils sont bien lancés en mode automatique et actuellement démarrés.
Bien vérifier qu’après un éventuel reboot de la machine les services sont toujours lancés.

(cf le site précisant ce type d’erreur et sa solution)

Correction de la déconnexion des clients MAC OSX

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

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