FreeBox Pro et VPN IPSec Site à site montés (P1 et P2 OK) mais très difficilement utilisables

fremois

Bonjour à tous
Je suis passé d'une FreeBox Delta à une FreeBox Pro il y a près d'un mois et je me retrouve avec un soucis dans l'usage de ma connexion Fibre que je n'avais pas avec l'offre Free Grand Public / FreeBox Delta

1/ Le contexte
Je suis connecté via des VPN site à site (en IPSec IKE v1) avec 9 autres sites. Tous ces sites ont des routeurs déployés par mes soins sous pfSense.
Ces sites sont connectés à l'internet via divers opérateurs :

2 x Orange Business avec la Box en mode Bridge (débit 250 Mb/s)
2 x Orange Pro (sans Box en "piquant" le vLan 835 - débit max. 500 Mb/s)
1 x SFR Business Pro Fibre avec le routeur opérateur en mode Bridge (débit 20 Mb/s)
1 x SFR Business Pro SDSL avec le routeur opérateur en mode Bridge (débit 2 Mb/s)
2 x Kosc (sans Box - en ppoe - débit max. 1 Gb/s)
1 x FreePro (avec la FreeBox Pro en forward tous ports / tous protocoles - débit max. 6 Gb/s)

2/ Sur la FreeBox Delta
Je n'avais aucun soucis pour joindre un des périphériques présents sur les LAN de ces sites distants et inversement aucune difficulté pour que ceux-ci atteignent une des ressources mise à leur disposition au sein de mon infrastructure.
Aucun soucis non plus de disponibilité de qualité de service ou de débit (selon les sites)

3/ Depuis la FreeBox Pro
Les VPN montent bien vers ces différents sites (Phases 1 et 2 de l'IPsec sans erreur) mais ils sont très difficilement exploitables :

a/ en HTTP
Si je cherche à faire une connexion en http (ou https) vers un équipement distant (un Nas, une borne Wifi, une imprimante, une VM,...) et que la première réponse est une redirection (code http "move" 301 ou 302), j'ai bien cette réponse qui arrive sur mon navigateur. Ce dernier appelle l'URL de destination et la connexion reste ouverte dans l'attente du code html mais rien n'arrive. En final le navigateur m'affiche le message de Time Out.

Si je fait un 'curl -i' j'ai bien l'entête de la réponse http dans tous les cas mais jamais le code html (connexion en attente, l'invite de commande ne revient pas)

b/ en SSH sous Linux
Je me connecte en SSH sur un équipement distant sans aucun soucis au niveau de l'identification mais :

je demande un 'ls -l' d'un répertoire de moins de 6 lignes environ : aucun soucis, j'ai la liste et récupère l'invite de commande
je demande un 'ls -l' d'un répertoire de plus de 6 lignes environ : j'ai bien le début de la liste puis plus rien avec une connexion en attente (l'invite de commande ne revient pas)
même chose avec les commandes 'more' ou 'cat'... l'éditeur 'pico' est inutilisable.
A chaque fois, je suis obligé de me déconnecter pour refaire une nouvelle connexion.

c/ En Remode Desktop (RDP ou ARD)
Les sites disposent de serveurs RDP et la connexion est possible mais avec l'impression d'une perte très importante de paquets. On a l'impression d'être connecté à travers une ligne totalement saturée ou une mauvaise ADSL (rafraichissement des écrans en basse définition puis montée de la résolution). Cela n'arrivait jamais avec la FreeBox Delta, on avait l'impression d'être en "local" sur les sites distants en fibre.

d/ Connexion hors VPN
Nous utilisons aussi beaucoup AnyDesk pour prendre la main sur des postes distants (ou en replis sur les serveurs) et nous rencontrons là aussi des latences, des délais de rafraichissements excessifs (comme en RDP) et des pertes de connexions qui nous conduisent à devoir quitter le logiciel pour pouvoir reprendre une nouvelle connexion.

e/ Test de débit
Cela n'est peut-être pas lié mais lorsque je faisais un test de débit avec le FreeBox Delta, j'étais entre 4 et 6 Gb/s alors qu'avec la FreeBox Pro je plafonne à 3/3,5 Gb/s

3/ Hypothèses
J'ai vérifié et re-vérifié toutes les règles de filtrage éventuelles au niveau des Firewalls mais je n'ai rien vu. Sur la liaison avec un des sites, j'ai même mis des règles de manière à tout laisser passer dans les deux sens mais cela ne change rien.

Une des hypothèses qui me parait plausible est celle d'une fragmentation excessive des paquets ou d'incompatibilité de MTU. En effet il est clair que la taille des paquets est un facteur déterminant de ce dysfonctionnement.
L'autre hypothèse pourrait être liée au fait que mon accès fibre Free Pro est configuré en IPv4 full stack (comme c'était le cas de la FreeBoc Delta)

Je cherche à revenir à un niveau de qualité de service tel que je l'avais auparavant car la situation actuelle pénalise lourdement mon activité.
J'ai aussi ouvert un ticket chez FreePro / Jaguar Network mais pour l'instant il est toujours ouvert et je cherche à fermer toutes les hypothèses au niveau configuration.
J'ose penser que c'est un soucis de paramétrage et suis près à passer du temps, vous communiquer des captures de trames (fichiers .pcap) et faire des tests pour trouver la solution à ce dysfonctionnement.

Je reste à votre disposition pour toute information complémentaire.
Merci par avance de votre aide et bonne journée
Francis

jdh

(Bravo pour la présentation de la question !)

Difficile d'avancer une piste sûre !

Je m'interroge toujours sur le mode bridge d'une box : comme Ipsec peut être configuré en NAT traversal, il n'y a pas forcément besoin d'avoir un bridge ! (Cette obsession d'éviter le double NAT ...)

A aucun moment vous ne parlez de dns : site par site, je verrais bien disposer obligatoirement d'un serveur avec des services minimum : dns, ntp, dhcp, lpr, ...

La piste du 'ls -l avec 6 fichiers' (= qui tient en un seul paquet) versus une grande liste (= qui nécessite plusieurs paquets) vont dans le sens du MTU, je suis d'accord. Est-il possible de fixer le MTU d'un lien Ipsec (et donc de le standardiser) ? (après test : pas de MTU dans la phase 2 sur pfSense ...)

Le lien https://blog.pingex.net/les-mtu-et-vous/ donne de multiples explications et un moyen de mesurer le MTU. Du fait de la multiplicité des opérateurs et des box/routeurs, le MTU est différent ...

fremois

@jdh Bonjour
Merci pour le compliment sur la présentation. Comme je dis souvent : "Même avec la meilleure volonté du monde, face à un "ça marche pas", je ne peux pas beaucoup vous aider..."

1/ Concernant le NAT : oui effectivement en laissant passer l'UDP sur les ports 500 et 4500, l'IPSec fonctionne. C'est le cas dans mes configurations.
2/ DNS : Tout l'adressage des ressources à travers le VPN se fait via l'adresse IP et très rarement sur le nom de celle-ci.
Les pfSense de tous les sites sont caches DNS (DNS forwarding), le ntp est activé au niveau du pfSense aussi bien en tant que client, pour récupérer l'heure sur le net, qu'en tant que serveur vis à vis des postes du LAN.
3/ DHCP : Les serveurs DHCP sont tous utilisés avec la majorité des attributions sur un bail permanent.
4/ MTU : Oui et je pense surtout à un problème de MTU entre la FreeBox Pro et le pfSense, car non présent lorsqu'il y avait la FreeBox Delta. Les soucis sont apparus dès le remplacement de la FreeBox Delta par la FreeBox Pro.
De même, en ce qui concerne la dégradation lorsque nous utilisons une solution de télémaintenance comme AnyDesk qui ne transite pas, à priori, par les VPN.
J'ai été obligé aussi de supprimer coté FreeBox Pro l'autonégociation du débit de son port SFP+ sur les conseils de Free Pro pour l'imposer en 10 Gb/s Full Duplex car sinon les speedtests ne dépassaient pas les 300 mb/s...
Dans pfSense, les seuls champs permettant de modifier le MTU sont dans le dialogue de l'interface (MTU et MSS).
Qu'elles sont les valeurs pertinentes que je pourrais tester ?

5/ Merci pour le lien sur le blog. Un point a retenu mon attention :
Un opérateur qui a pour politique de dropper les fragments IP: il y a donc perte de données (très dur à débugger),
Un firewall configuré pour dropper l’ICMP: un problème de fragmentation rencontré sur le réseau ne sera pas remonté à l’expéditeur car l’ICMP est bloqué. Ce dernier ne pourra donc pas se rendre compte du problème et continuera alors à envoyer des paquets qui iront à la poubelle, ou bien attendra un acquittement TCP qui n’arrivera jamais. De plus bloquer l’ICMP empêche le PMTUD de fonctionner correctement,...

Or le passage de la FreeBox Delta à la FreeBox Pro s'assimile à un changement d'opérateur et de réseau de collecte puisque la FreeBox Delta est sur le réseau Free alors que l'offre FreeBox Pro est sur le réseau géré par Jaguar Network.

Complément :
Une autre "bizarrerie" que je ne m'explique pas :
Pour tous les sites, je peux me connecter sur l'interface Web des pfSenses en utilisant leur adresse IP LAN à l'exception... de l'autre site connecté via FreePro et sa box.

J'ai aussi paramétré les VPN Mobiles en IPSec/IKEv2 et je n'ai pas de soucis d'accessibilité aux ressources de mon réseau lorsque je suis connecté depuis l'extérieur.

J'ai posté ma question également sur un forum que je sais consulté par un des développeurs du firmware de la FreeBox Pro...

A suivre ...

jdh

@fremois said in FreeBox Pro et VPN IPSec Site à site montés (P1 et P2 OK) mais très difficilement utilisables:

Un opérateur qui a pour politique de dropper les fragments IP: il y a donc perte de données (très dur à débugger),

Ce n'est pas le cas, si NAT traversal est actif (peut-être essayer en Actif et non Auto). Dans votre cas, hors le trafic LAN vers Internet, le trafic LAN vers autres sites passe en Ipsec.

J'ai appris qu'Ipsec utilise 28 octets par trame, ce qui est énorme.

Le réglage MTU de pfSense concerne le trafic global du pfSense, et non celui de flux Ipsec. Il serait judicieux de tester chaque routeur pfSense : il est probable qu'il ne sera pas le même, du fait des différentes marques : peut-être le fixer à la valeur mini ? Cela ne devrait pas être très éloigné de 1492 ...

jdh

Edit :
j'ai mal lu : un opérateur qui filtrerait les paquets fragmentés ???
Cela me parait impossible !

Par contre, les box parlent allègrement de DMZ en transférant le traficTCP et UDP, or il y a bien d'autres protocoles, à commencer par ICMP ... (et ESP ou AH utilisés par Ipsec =sans NAT Traversal)

nicolas-R

Bonjour,

Je me suis inscrit juste pour te répondre.
J'ai exactement le meme problème.
VPN IPSEC entre plusieurs stormshield (du coup on peux ecarté un soucis de PFSENSE ? )
-Ping OK
-page web du stormshield KO
-SSH vers le Stormshield OK

C'est une freebox "Pro" avec freebox OS.

Si je n'active pas la fragmentation IKE le tunnel ne monte pas.

Je pense aussi à un soucis de MTU.

Je vais voir si je peux modifier le MTU à des fins de test sur le stormshield.

Nicolas

fremois

@nicolas-r
Bonjour Nicolas
« Content » d’apprendre que je ne suis pas le seul…
Je suis en relation avec le support Free Pro pour ce problème et je vais pouvoir leur faire suivre le fait que ce n’est pas exclusivement de mon côté que me soucis se situe …
Lorsque la solution sera trouvée, je la posterai sur ce fil voir en faire un tuto !
Bonne journée

nicolas-R

Hello,

En baissant le MTU à 1000 j'ai du mieux ( je n'ai pas testé des valeurs entre 1500 et 1000 j'ai directement mis 1000)

L'interface admin du stormshield est accessible via l'ipsec.
Le SSH vers le stormshield ne crash plus quand on fait une requête qui affiche trop de ligne.

C'est une freebox Server (r2) (une freebox revolution je pense ?). La connexion est une VDSL et la freebox est en mode routeur. Freebox OS est en version 4.5.4

Mon réseau est composé de 12 stormshield. 1 Stormshield centrale qui est le HUB IPSEC.
Tous les autres stormshield se connecte au HUB en IPSEC en mode mobile (il n'y a pas de redirection du port 500 et 4500 sur les sites distants)

Je n'ai rencontré ce problème que sur le site ayant une connexion free. Les autre sites ayant des connexions diverses ne posent pas de problème (Orange, Bouygues, OVH, FAI PRO, même de la 4G)

Prochaine étape. Trouvé la valeur max limite du MTU. En sachant que en local le ping ne fonctionne plus avec un MTU max de 1472 ce qui est normal.

Nicolas

jdh

Normalement on ne devrait pas toucher au MTU, mais ...

La bonne approche est de mesurer sur chaque site le MTU (local), puis de le fixer au minimum de tous les MTU mesurés.

(Le faire empiriquement n'est pas très scientifique ...)

(En local avec ethernet, il est la plupart du temps à 1472.)

NB : pour tester, on fait (Windows) 'ping -f -l xxxx (adr ip ou nom dns)', ce qui est simple à réaliser. (Curieux que l'on teste le MTU destiné à TCP par ping= ICMP !)

Mth13u

Bonjour,

Le sujet m’intéresse car nous rencontrons le même problème sur un site connecter avec une freebox pro.

nicolas-R

@mth13u en baissant le MTU c'est stable maintenant. je l'ai positionné à 1400.

Mth13u

Merci @nicolas-R je vais tester t'as solution.