FreeBox Pro et VPN IPSec Site à site montés (P1 et P2 OK) mais très difficilement utilisables
-
@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 ...
-
@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 ...
-
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)
-
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 OKC'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
-
@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 -
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
-
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 !)
-
Bonjour,
Le sujet m’intéresse car nous rencontrons le même problème sur un site connecter avec une freebox pro.
-
@mth13u en baissant le MTU c'est stable maintenant. je l'ai positionné à 1400.
-
Merci @nicolas-R je vais tester t'as solution.