Problème d’usage une fois connecté au VPN via 4G (partage de connexion avec un smartphone)

mai 24th, 2022

Description du problème

Nous avons remarqué chez un opérateur (pour le moment) une modification des caractéristiques de connexion des données mobiles.

En effet, l’opérateur Orange a fixé le paramètre “protocole APN” à “IPv6” seul.

Dans ce cas, l’opérateur effectue une translation IPv6/IPv4 et fournit une IPv4 non fixe. Le site http://monip.org donne une IPv4 qui est différente de celle reçu par le serveur VPN.

Du coup, la connexion VPN est bien effectuée, mais elle n’est pas fonctionnelle.

Première solution

Il faut si cela est possible avec votre téléphone (exemple, sous Samsung, cela n’est pas réalisable) effectuer un changement du champ “protocole APN” pour le passer en IPv4.

  1. Rendez-vous dans Paramètres ou Réglages.
  2. Selon le téléphone et version d’Android que vous utilisez, sélectionnez Sans fil et réseaux ou Plus ou Données mobiles ou Paramètres supplémentaires ou Plus de réseaux (accessibles depuis Connexions) ou réseaux et partage de connexion (accessible depuis Réseaux).
  3. Sélectionnez ensuite Réseaux mobiles.
  4. Choisissez Nom des points d’accès.
  5. Effectuer la modification du champ
  6. ne pas oublier de sauver la configuration (bouton … en haut à droite puis “sauvegarder”)

Deuxième solution

Si le paramètre n’est pas modifiable, il faut créer un nouveau point d’accès.

  • Allez dans le menu Réglages ou Paramètres.
  • Sélectionnez Réseaux mobiles
  • Cliquez sur Noms des points d’accès et créer un nouvel APN.

Les paramètres internet sont les suivants :

  • Nom : Orange Internet
  • APN : orange
  • Proxy : Non défini
  • Port : Non défini
  • Nom d’utilisateur : orange
  • Mot de passe : orange
  • MMSC : Non défini
  • MMS Proxy : Non défini
  • Port MMS : Non défini
  • MCC : 208
  • MNC : 01
  • Type d’authentification : PAP
  • Type d’APN(nom du point d’accès) : default,dun,supl,mms,xcap
  • Protocole APN  : IPv4
  • Protocole de roaming APN : IPv4

Sélectionnez la nouvelle connexion créée et l’accès au VPN sera propre (car en IPv4).

Options nécessaires

avril 6th, 2022

Sur une installation manuelle ou sur une mise à jour, il est possible que les deux options (entourées de rouge sur l’image suivante) de la connexion VPN soient invalidées.

Sans une revalidation de ces options, votre connexion au serveur VPN ne fonctionnera pas.

(Merci à Stéphane Daumas pour sa patience et l’ensemble des tests que nous avons effectués avec lui).

Fin prévu de vpn14 et évolution de vpn20

janvier 6th, 2022

Bonjour à toutes et tous,

depuis 2008, le VPN évolue pour rendre un service plus simple (souvent) et plus sécurisant (toujours).

Voici le rappel des versions successives :

  • 2008-2014 : vpn1 (Besançon), vpn2 (Montbéliard), vpn3 (Belfort) en IPSEC/ikeV1/L2TP
  • 2014-2020 : vpn14 IPSEC/ikeV1/SHREW
  • 2020-2022 : vpn20-1, vpn20-2 IPSEC/ikeV2/natif OS

La pandémie et l’accélération du “travail à la maison/télétravail” a fait prendre conscience à chacun de la nécessité des outils de travail à distance. Le VPN a donc évolué en 2020 pour en faciliter l’accès.

Serveur vpn14, connexion SHREW

Nous projetons maintenant la fermeture de l’ancien serveur vpn14 (ikev1/shrew) pour juillet 2022.

Si vous possédez un accès VPN avec SHREW, il faudra penser à évoluer sur la nouvelle infrastructure.

Administration du service

Dans le même temps, nous allons changer de procédure de création des droits d’accès au VPN pour le déléguer aux composantes et laboratoires. La création de certificat n’étant plus nécessaire, cette délégation permettra de simplifier la mise en place des droits des usagers sur les realms @ufc et @ufc-pub d’une part et sur les realms spécifiques d’autre part.

MFA (Multi-Factor Authentication)

Nous allons mettre en place pour le VPN un 2FA (Double Authentification). Cette mesure permettra de sécuriser un peu plus les accès au sein de l’UFC.

Le moyen retenu pour le moment est Google Authenticator.

Cela se concrétise par l’usage d’un code (généré par une application ou un add-on de navigateur) à la fin de votre mot de passe.

L’application se base sur la date, l’heure et un nombre tiré au hasard (propre à votre instance d’application et au système d’authentification de l’UFC pour votre compte) pour générer le code à appliquer en plus de votre mot de passe. Code qui certifiera que vous êtes bien la personne qui doit être authentifiée.

Tester son MTU sous Windows

décembre 15th, 2021

Vous pouvez trouver l’outil mtupath.exe (https://www.iea-software.com/products/mtupath/).

Une fois chargé dans votre répertoire, ouvrez une console CMD.

cd %userprofile%\Downloads ;
mtupath.exe vpn20-2.univ-fcomte.fr ;

il va sortir des informations du style :

MTU path scan to vpn20-2.univ-fcomte.fr (194.57.91.249), ttl=64, limit=48 # 21 best MSS 1412 (estimated MTU 1440) [pPPPPpPppP****ppPPP**]

#1 MSS IN RANGE 1 <== 1411 ==> 1412
#2 SCAN TIMEOUT 1413 <== 31 ==> 1444
#3 MSS EXCEEDED 1445 <== 14939 ==> 16384

[WARNING] Possible PMTU blackhole in route to peer

A partir de là si vous regarder l’état du MTU de l’interface avec laquelle vous vous connectez au VPN :

netsh interface ip show interfaces

Vous pourrez facilement faier un réglage plus adéquat :

netsh interface ipv4 set subinterface “nom de l’interface listée ci-dessus” mtu=XXXX store=persistent

VPN et TGV

décembre 15th, 2021

Il est possible que dans le TGV votre connexion VPN n’aboutisse pas.

Nous avons fait certains réglages en fixe dans les attributs de la connexion VPN qui ne sont peut-être pas les bons lorsque vous utilisez le VPN dans le TGV.

La solution est de faire un réglage du MTU de la connexion réseau que vous utilisez pour le VPN avec une valeur différente de celle fixée.

Pour cela, ouvrez une fenêtre shell (commande CMD). Ensuite, faire dans la fenêtre CMD

netsh interface ip show interfaces

Vous obtenez la liste des interfaces réseau que vous utilisez sur votre machine.

Choisissez l’interface WIFI (vu que vous êtes dans le TGV).

Tapez la commande dans la fenêtre CMD :

netsh interface ipv4 set subinterface “le nom de l’interface wifi” mtu=1264 store=persistent

Et essayez de relancer votre connexion VPN. Avec cette nouvelle valeur, la connexion devrait être correcte.

Problème de navigation une fois le VPN activé suite à upgrade en debian 10.10 et ubuntu 20.04/21.04

septembre 15th, 2021

Il est possible que la connexion au VPN (vpn20-1, vpn2-2 ou vpn20-3) via la WIFI ne fonctionne pas correctement.

Il se trouve que sur ces OS récents, il n’est plus possible de faire le réglage de la MTU via les paramètres graphique de la connexion WIFI.

Un ip address va vous informer sur l’état de votre conenxion.

Exemple :

dsin@dsin-NL40-50GU:~$ ip address
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: wlp0s12f0: mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 24:41:8c:68:37:56 brd ff:ff:ff:ff:ff:ff
inet 172.21.205.141/20 brd 172.21.207.255 scope global dynamic noprefixroute wlp0s12f0
valid_lft 4992sec preferred_lft 4992sec
inet 10.248.3.19/32 scope global wlp0s12f0
valid_lft forever preferred_lft forever
inet6 fe80::3c5:7d40:52b7:1452/64 scope link noprefixroute
valid_lft forever preferred_lft forever

ce qu’il faut voir ici est la ligne :

2: wlp0s12f0: mtu 1500 qdisc noqueue state UP group default qlen 1000

Qui indique un MTU à 1500 octets.

Ainsi la connexion VPN basé sur le WIFI n’est pas fonctionnelle.

Il faut ré-appliquer “à la main” la procédure suivante (merci à Sébastien Picard d’avior été vigilent sur ce point) dans le fichier /etc/NetworkManager/dispatcher.d/01-ifupdown :

if [ "$2" = "vpn-up" ] || [ "$2" = "vpn-down" ]; then
ADDRESS_FAMILIES=""
ip link set dev "$1" mtu 1300
fi

Une fois cela fait vous pouvez arrêter le VPN, relancer la connexion WIFI et relancer la connexion VPN.

Statistiques des connexions VPN 01/01/2019 – 01/04/2021

avril 28th, 2021

La courbe entre janvier 2019 et février 2021 est l’activité normale pré-covid19. Il n’y avait alors qu’un seul serveur VPN actif (vpn14). Dès mars 2021, le serveur vpn20-1 et surtout vpn20-2 ont été ajoutés pour permettre d’absorber les nombreuses connexions induites par le “travail à la maison”. En décembre 2020, le serveur vpn20-2 a migré de l’infrastructure de virtualisation sur une machine dédiée. Cela a permis de passer un nouveau cap de connexions simultanées.

Graphe des connexions VPN durant les confinements successifs.

IKEv2 & Windows 10 : message d’erreur “Paramètres incorrects”

mars 26th, 2021

Si vous utilisez le script powershell pour créer la connexion VPN en IKEv2 sous Windows 10 (comme indiqué dans les instructions d’installation) et que, lorsque vous essayez de vous connecter, le message “parameter is incorrect” apparaît, procédez comme suit :

  • 1. Effacer les caches réseau

Exécutez la fenêtre cmd de Windows (cliquez sur le menu de démarrage de Windows, tapez ‘cmd’, faites un clic droit sur ‘Command Prompt’ et sélectionnez ‘Run as Administrator’).

Tapez la commande suivante :
netsh int ip reset

puis tapez :
netsh int ipv6 reset

puis tapez :
netsh winsock reset

Redémarrez votre ordinateur.

  • 2. Réinitialiser les adaptateurs du Gestionnaire de périphériques

Ouvrez le Gestionnaire de périphériques
Trouvez les adaptateurs réseau
Désinstaller les pilotes WAN Miniport (IKEv2, IP, IPv6, etc.)
Cliquez sur Action > Analyser les changements de matériel
Les adaptateurs que vous venez de désinstaller devraient réapparaître.

La connexion VPN fonctionne alors.

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

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.

Linux : problème de connexion (chaîne de certification)

mars 23rd, 2020

Si votre système (ubuntu 18.xx par exmple) n’est pas bien à jour, il est possible que la chaîne de certification qu’il embarque ne soit plus valide. Cela est visible sur certains serveurs Web en https certifiés par Digicert, mais du coup aussi sur les serveur VPN vpn20-1 ou vpn20-2 qui utilise également ce type de certificat et de chaîne de certification.

Le log (merci Clément) :

Mar 23 07:51:31 SCI-DIEBOLD4 charon-nm: 09[IKE] no trusted RSA public key found for 'vpn20-2.univ-fcomte.fr'

Sur le serveur VPN nous avons cela :

Mon, 2020-03-23 07:51:31 10[ENC] parsed INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
Mon, 2020-03-23 07:51:31 10[ENC] generating INFORMATIONAL response 2 [ N(AUTH_FAILED) ]

Pour corriger le problème et réussir à établir la connexion, Clément nous à fourni la solution :

dpkg-reconfigure ca-certificates
(vous pouvez laisser tous les certificats coché, sinon celui qui est impératif est celui de Digicert)
update-ca-certificates