Connexion OpenVPN OK mais problème d'accès aux dossiers suivants les opérateurs
-
Bonjour
Je suis prestataire informatique pour des petites entreprises et depuis plus d'1 an j'ai installé une dizaine de parefeu pfsense pour différents services dont plusieurs accès distants OpenVPN.
J'avoue ne pas être un expert réseau, loin de là, et je suis face à un problème assez complexe de mon point de vue que je vais essayer d'exposer clairement.
Contexte : milieu pro, niveau d'expertise basique de l'administrateur
Besoin : accès distant en VPN pour des clients nomades
Schéma :
Routeur 4G Bouygues (192.168.10.1) et une ligne ADSL connectés à un routeur Cisco (qui gère le load balancing).
Le Routeur Cisco offre 2 ports, dont 1 avec adresse IP publique sans restriction.
Sur ce port (adresse IP publique) j'ai branché un parefeu PFSense SG-1100 et configuré le WAN avec IP et passerelle fournie par Bouygues
Derrière le parefeu PFSense j'ai mon réseau qui existait déjà en 192.168.1.0
IP parefeu : 192.168.1.1
IP serveur DNS (serveur Windows) : 192.168.1.10J'ai paramétré un serveur OpenVPN et des clients nomades (ordinateurs portables).
Dans tous les scénarios les clients se connectent avec succès au VPN et pinguent parfaitement le parefeu, le serveur windows et le NAS.
En revanche l'accès aux dossiers du serveur et du NAS n'est possible que dans certains scénarios, ceci dépend du type de connexion et du fournisseur d'accès du client.Client connecté en ADSL ou Fibre : OK tout foncitonne
Client connecté en partage de connexion mobile Free : OK tout foncitonne
Client connecté en partage de connexion mobile Orange ou Bouygue : ping OK, ouverture racine dossiers OK, navigation dans les dossiers impossible.avec le même ordinateur, le fait de passer de la 4G à un réseau wifi box suffit à permettre l'accès aux dossiers, sinon l'explorateur Windows ne répond pas et le sablier tourne longuement jusqu'à dire : dossier vide.
Pour information je n'ai pas d'accès aux routeur Cisco, Bouygues se réserve cet accès.
Je ne sais pas trop quelles autres informations vous donner mais n'hésitez pas à demander.
Je vous remercie de bien vouloir m'aider.
-
Selon les informations fournies, je dirait à prima bord qu'il s'agit d'un problème de MTU, ou plutôt que les paquets ICMP indiquant que la fragmentation est nécessaire sont bloqués quelque part en amont. (Voir https://fr.wikipedia.org/wiki/Path_MTU_discovery).
Il est possible d'ajuster le paramètre MSSFIX de la connexion OpenVPN à 1400 autant dans le serveur que dans le client, et donc en réduisant la taille des paquets ça pourrait contourner le problème.
Bien qu'il faudrait faire des captures de paquet afin de déterminer si il s'agit bien d'un problème de MTU, un simple essai en réduisant la taille des paquets pourrait être très révélateur. -
Merci beaucoup, voilà 4 jours que je me prends la tête.
Ça marche mais j'ai du mettre 1200, avec 1400 ça ne marche pas non plus.
merci encore et encore
-
(Bonne présentation avec utilisation du formulaire : bravo, à continuer)
(Au passage, on voit bien que cela dépend de cleui qui veut poser son problème ...)Le problème est difficile parce qu'il semble variable : plusieurs installations semblables avec des réglages semblables mais avec des opérateurs distincts.
Quand le ping fonctionne et que certains protocoles ne fonctionnent pas, on peut, en effet, suspecter le MTU : le MTU est la taille maximale de paquet IP qui passe.
Ici, cela a semble-t-il résolu le problème. Mais mon conseil est de toucher au MTU quand tout a déjà échoué, parce qu'en principe le MTU par défaut est normalement respecté et qu'en conséquence toucher le MTU ammène à des problèmes plutôt qu'à des solutions ...
-
@jdh Selon mon expérience ce que @Akonkauak décrit, dans sa bonne présentation, tombe directement en ligne avec un problème relié au MTU.
Malheureusement, il existe des personnes "techniques" peu-allumés qui travaillent dans des boites de fournisseur Internet qui ne comprennent pas l'importance du protocole ICMP et s'amusent à le bloquer aléatoirement, remarque on voit ça de moins en moins, mais il y a 10 ans c'était la folie!
En finale, le résultat de telles actions sont les transferts de données qui marchent à moitié.Bien que le MTU d'Ethernet est de 1500 octets, on retrouve fréquemment des éléments de réseau qui réduisent la taille du paquet à cause d'une encapsulation quelconque, par exemple le PPPoE où le MTU se trouve à être 1492. Du coté du fournisseur, il peuvent aussi se servir de tunnels IPSEC ou GRE pour acheminer les données du client, qui peuvent réduire le MTU original d'avantage. D'ailleurs c'est pour cela que dans le RFC du protocole IPv6 ils indique que le MTU minimum qui doit toujours être respecté est de 1280. Dans le cas de IPv4 c'est 68 octets, mais c'est bien trop petit pour être utile donc 576 octets c'est plutôt la norme.
Il y a une excellente description des enjeux ici: https://www.cisco.com/c/fr_ca/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.htmlJe recommanderais @Akonkauak de trouver la valeur maximale à laquelle ça fonctionne correctement puisque 1200 me semble un peu bas.
À titre de référence du manuel OpenVPN
–mssfix max
Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed maxbytes. The default value is 1450. -
Je suis totalement d'accord avec awebster : tout ce qui est écrit est parfaitement exact : les protocoles qui 'mangent' quelques octets à la trame maximum, et donc, réduisent le MTU. (Le 1492 du PPPoE est bien connu.)
(Autrefois, on configurait les 'bastions' (=firewall) pour refuser les paquets avec fragmentation !)Ce que je veux dire, c'est de penser au MTU qu'en dernier. Par exemple, puisque c'est l'accès à des NAS et la navigation dans des partages (Windows, donc CIFS/SMB), on aurait pu d'abord penser à des problèmes DNS. On doit modifier le MTU qu'en cas ultime !
