Posts Tagged ‘windows’

« Older Entries

Windows : dysfonctionnement, première liste de vérification

jeudi, août 29th, 2024

Si la connexion VPN est active et que les sites universitaires ne sont pas accessibles, voici une liste à vérifier :

  • Vérification de la MTU de l’interface utilisée pour faire la connexion VPN. Cette connexion sera le plus souvent la connexion WIFI.
    Se référer à l’article sur la correction du MTU.
  • Priorité de routage : la sortie par défaut (par exemple 35) doit être inférieure à la route vers le serveur VPN (194.57.91.249/250/251/252/… par exemple 36) et les routes vers les sites universitaires inférieurs a la sortie par défaut et le serveur VPN (par exemple 11).
    Si cela n’est pas bon, il faut détruire la connexion et la recréer à partir du script (cf procédure de connexion, problème de métrique, problème avec le script, …).
  • Windows a tendance à positionner le proxy de manière automatique. Il faut le désactiver en positionnant “pas de proxy”. Pour ce faire, vous pouvez passer par votre navigateur internet, dans les propriétés, recherche “proxy”.

Tags:, , , ,
Posted in Informations utilisateurs, problèmes utilisateurs | No Comments »

Windows, modification de la MTU

mardi, mai 28th, 2024

Voici un script qui modifie la base de registre pour y placer directement la bonne valeur de MTU. En effet, nous nous sommes rendu compte que parfois la modification manuelle (à partir de l’interface réseau) n’était pas prise en compte correctement. En modifiant la base de registre, la valeur affectée est la bonne.

Voici le programme set-vpn-mtu.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NdisWan\Parameters\Protocoles]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NdisWan\Parameters\Protocoles\0]
"ProtocolType"=dword:00000800
"PPPProtocoleType"=dword:00000021
"TunnelMTU"=dword:00000514

Tags:, ,
Posted in informations techniques, Informations utilisateurs, problèmes utilisateurs | No Comments »

Création de la connexion VPN par le script ou manuelle échouent

mardi, février 6th, 2024

Une erreur de création de l’interface VPN (UFC VPN) et des routes par :

  • exécution du script dans une fenêtre CMD ;
  • exécution du script dans une fenêtre PowerShell ;
  • en tapant les commandes du script à la main dans une fenêtre PowerShell ;
  • création manuelle (l’interface semble inaccessible [cf image plus bas]).

Si la configuration semble Ok (cf image plus bas) :

En fait, il manque le “WAN Miniport (IKEv2)” dans le gestionnaire de périphériques de l’ordinateur.

Le “Windows Driver Kit” devrait permettre d’ajouter le module manquant et à la connexion VPN de pouvoir s’établir.

Tags:, , , ,
Posted in problèmes utilisateurs | No Comments »

Exécution du script “désactivé”

vendredi, février 2nd, 2024

Si sous PowerShell de Windows 10 ou 11 vous avez l’erreur “Exécution de scripts est désactivée“, deux méthodes pour arriver à exécuter le script

** Vous pouvez soit exécuter le script avec la commande suivante

Powershell.exe -ExecutionPolicy Bypass "creerVPNUFC.ps1"

** ou vous pouvez exécuter la ligne suivantes (toujours sous PowerShell)

set-executionpolicy unrestricted

Valider par “O” et ensuite le script pourra s’exécuter normalement.

La cause première de l’erreur provient du script qui est non-signé par l’infrastructure de PKI du domaine (ou autre). Une PKI de domaine universitaire corrigera le problème (un nouveau projet ?!).

Tags:, ,
Posted in problèmes utilisateurs | No Comments »

Windows : ajouter un serveur DNS indépendant de ceux de l’UFC

lundi, mars 23rd, 2020

Si votre serveur DNS n’est pas associé à un sous-domaine universitaire sur le DNS de l’UFC, alors la connexion VPN en vous imposant les 194.57.91.200 et 201 va empêcher les connexions vers vos serveurs nommés sur votre serveur de nom (par exemple 172.20.7.250).

Pour corriger cela, vous devez avoir les droits d’utiliser Powershell sur votre poste Windows (droit administrateur).

La ligne suivante permet l’ajout de votre serveur de nom. Mais pour que celui-ci soit pris en compte il faut interrompre la connexion VPN, taper la ligne et relancer la connexion VPN.

Add-VpnConnectionTriggerDnsConfiguration -ConnectionName "VPN CTU" -DnsSuffix ".univ-fcomte.fr" -DnsIPAddress "172.20.7.250" -PassThru

Pour enlever cet ajout :

Remove-VpnConnectionTriggerDnsConfiguration -ConnectionName "VPN UFC - VPN20-2 - CTU" -DnsSuffix .univ-fcomte.fr

Et là aussi, il faut arrêter et relancer la connexion pour que cela soit pris en compte.

Tags:,
Posted in Informations utilisateurs | No Comments »

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

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

Tags:, , , , ,
Posted in Informations utilisateurs | No Comments »

Windows 10 et route par défaut

mercredi, 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.

Tags:, , ,
Posted in Informations utilisateurs, problèmes utilisateurs | No Comments »

Pas de réseau

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

Tags:, , , , , , ,
Posted in Informations utilisateurs, problèmes utilisateurs | No Comments »

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.

Tags:, ,
Posted in informations techniques, problèmes utilisateurs | No Comments »

Windows + SHREW message “network unavailable”

mardi, septembre 30th, 2014

Plusieurs configuration peuvent amener le message “network unavailable” dans SHREW.
1) plusieurs connexions réseaux sont actives au même moment. Il suffit de désactiver celles qui ne sont pas utile.
2) Vous avez un firewall du commerce. Celui ci bloque peut-être la connexion VPN => vérifier s’il ne faut pas le désactiver
3) Vous avez plusieurs Firewall/Anti-Virus. Le cas le plus probable étant d’avoir un Firewall du commerce en plus du Firewall de Microsoft.
Dans ce cas vous pouvez désactiver correctement le FW Microsoft en cliquant sur le menu “démarrer”
– clique droit sur l’onglet “Ordinateur”
– choisir “gérer”
– cliquer sur l’onglet “services”
– choisir “Par feu Windows” et désactiver le service

Rebooter la machine et relancer SHREW

Tags:, ,
Posted in problèmes utilisateurs | No Comments »

« Older Entries