Archive for the ‘problèmes utilisateurs’ Category

Problème de connexion sur iPhone depuis le 28/11/2025

mercredi, janvier 21st, 2026

(test et configuration par notre collègue Fabien Donolo)

Il est possible, avec un iPhone, que la connexion VPN ne fonctionne plus depuis le changement de certificat du serveur VPN.

Les cas identifiés pour le moment sont la non reconnaissance de la CA de HARICA auquel est attaché le certificat des serveurs VPN.

La solution possible est de suivre la procédure d’installation de la WIFI eduroam en passant par le site https://cat.eduroam.org

Cela permet d’installer proprement la CA HARICA sur le téléphone.

Au niveau de la configuration VPN de l’iPhone, prendre garde au fait que le champ « id distant » doit contenir l’adresse du serveur VPN.

Ubuntu et problème de résolution de nom sur l’uMLP

vendredi, janvier 16th, 2026

Sur la version 22 d’ubuntu, un usager a noté un problème de DNS.

Les résolutions de nom vers l’extérieur fonctionnent normalement, mais vers l’intérieur, certaines résolutions ne donnent pas de résultats.

La solution de l’usager (merci à Aflah Elouneg pour sa persévérance) pour résoudre ce problème est la suivante :

J’ai réussi finalement à faire fonctionner le VPN. C’était un problème de DNS. Je l’ai remis par défaut (au lieu de le pointer vers un dnsmasq.d)

[main]
plugins=ifupdown,keyfile
dns=default

[ifupdown]
managed=false

[device]
wifi.scan-rand-mac-address=no

Linux : le tunnel vpn est monté mais les ressources universitaires ne sont pas joignables.

mercredi, août 13th, 2025

Plusieurs cas de PC portables sous Linux (Ubuntu et Mint) nous ont été remontés pour lesquels le tunnel VPN monte correctement mais les ressources universitaires ne sont pas joignables. Nous avons d’abord pensé à un problème de MTU souvent caractérisé par ce comportement. Mais en l’occurrence, la MTU était bien paramétrée.

Après consultation des logs des machines, on retrouve systématiquement les éléments suivants (https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg6086890.html) :

ago 09 08:30:59 vmubuntu2404 kernel: nm-xfrm-1839711: Local routing loop 
detected!
ago 09 08:30:59 vmubuntu2404 kernel: nm-xfrm-1839711: Local routing loop
detected!
ago 09 08:30:59 vmubuntu2404 kernel: nm-xfrm-1839711: Local routing loop
detected!
ago 09 08:30:59 vmubuntu2404 kernel: nm-xfrm-1839711: Local routing loop
detected!
ago 09 08:30:59 vmubuntu2404 kernel: nm-xfrm-1839711: Local routing loop
detected!
ago 09 08:30:59 vmubuntu2404 kernel: nm-xfrm-1839711: Local routing loop
detected!

La solution consiste à arrêter le service strongswan-starter (qui démarre le service strongswan en tant que serveur) qui vient en conflit avec network-manager-strongswan.

Voici les instructions nécessaires pour connaître le status de ce service :

[sudo] systemctl status strongswan-starter

ou :

[sudo] service strongswan-starter status

Voici les instructions nécessaires pour arrêter ce service :

[sudo] systemctl stop strongswan-starter

ou :

[sudo] service strongswan-starter stop

Le mieux consistera à désinstaller ce paquet avec la commande suivante :

[sudo] apt purge strongswan-starter

Dans le cas d’une installation « vierge » d’Ubuntu 24.04, ce problème ne se pose a priori pas : le service strongswan-starter n’est pas installé. Les paquets strictement nécessaires au bon fonctionnement du vpn sont :

  • network-manager-strongswan
  • libcharon-extauth-plugins
  • libcharon-extra-plugins
  • libstrongswan-extra-plugins

Windows : « charge utile non valide reçue »

mardi, avril 8th, 2025

Cette erreur semble se produire sur vpn20-2 uniquement. Ce serveur est le plus chargé de ceux mis en service du fait que, par défaut, c’est le serveur de tous les personnels et étudiants. Il s’agit sans doute d’une erreur due à une mise à jour de l’OS Windows 11, sans que nous puissions en déterminer l’origine exacte.

Dans le cas ou cela se produit, vous pouvez placer en lieu et place de « vpn20-2.univ-fcomte.fr » le serveur « vpn20-1.univ-fcomte.fr ».

En effet, vpn20-1 n’est pas en standard dans les configurations. Il n’a donc, actuellement que peu de connexions concomitantes.

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 ».

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

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.

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 ?!).

Ubuntu 22 et installation

mardi, novembre 7th, 2023

lors de l’installation avec la documentation du VPN sur une Ubuntu version 22 un problème de MTU peut apparaître. L’outil graphique nmtui permet de vérifier et de corriger le problème.

Déconnexion au bout de 2h/8h

jeudi, octobre 26th, 2023

Nous n’avons pas à ce jour identifié le problème des déconnexions non demandées au bout de 2h ou 8h.

Les pistes sont :

  • utilisation réseau trop importante et incapacité pour le poste client de maintenir sa connexion avec le serveur VPN
  • l’anti-virus local ou le pare-feu local coupe la connexion suite à un time-out qu’il a définit
  • la version de Windows installée est d’origine de l’achat et celle-ci contient des variables définissant un time-out pour les connexions