comment le débit est mesuré ?

Je vous invite à prendre connaissance de ce post Github (nous sommes 3 à constater un problème avec certains protocoles) https://github.com/LaFibre-info/Freepro/issues/37

Oui j'ai vu ce post mais github n'est pas un forum mais un "bug-tracker".
Le bug #37 (https://github.com/LaFibre-info/Freepro/issues/37) concerne un souci du serveur VPN de la box elle-meme quand on veut "exiger le chiffrement" dans la config d'un client.

La on parle de 'bridage' ou performance d'un trafic VPN (IPSEC) entre 2 serveurs VPN et ce n'est pas clair si c'est la Freebox Pro est un des serveur (termine t'elle le tunnel IPSec ou passe-il  juste a travers ?).

Si vous mélanger les sujets et les problèmes sur github ca spam et embrouille ceux qui suivent les bugs (chaque commentaire sur github génère l'envoi d'un email a ceux qui suivent les bugs).

Il faut clarifier et identifier le problème et éventuellement ouvrir un nouveau bug sur github concernant un souci de performance quand IPSEC traverse le réseau Free/JN (c'est peut-être pas la Freebox Pro le problème la).

On sait déjà que la Freebox Pro ne permet pas d'envoyer du ESP/GRE/... vers la  DMZ  (en entrée donc) mais en sortie ca devrait fonctionner.

D'ailleurs si y'a du bridage constaté c'est que le trafic passe donc a ce niveau y'a pas de 'bug'.
Si y'a vraiment du bridage il faut essayer de comprendre pourquoi avant et ensuite si la box ou le réseau de Free/JN est vraiment en cause alors éventuellement ouvrir un ticket au support Free et ouvrir un nouveau bug dans le github (qui je le rappelle est non officiel donc ouvrez toujours un ticket au support en plus).

Les deux potentielles causes seraient :

- Problème de Fragmentation MTU/MSS avec Jaguar Network / Free.
- Problème avec les protocoles ESP / AH / GRE entrants sur la Freebox.

pour la mtu ca se test facilement (cf commandes tracepath sous Linux, traceroute sous FreeBSD) est-ce que le tunnel pas au dessus d'IPv6 ou IPv4 ?

Mais c'est peut-être plutôt un problème de saturation/limitation du trafic UDP entre JN et OVH (a un époque OVH et Orange avait ce souci entre eux).

Un test avec iperf3 en UDP sera une bonne chose à faire pour voir le taux de perte (ou autre) par exemple et pour savoir si le problème est au niveau UDP ou au dessus.

J'utilise Wireguard (avec Tailscale) entre des machines derrière une Freebox Pro et des machines chez Online et d'autres derrière une Livebox Pro Fibre et aucun souci de débit de tunnel dans les 2 sens. J'ai plus de VPS chez OVH depuis l’incendie donc je ne peux tester avec OVH. Apres c'est du trafic UDP sur IPv6.

L'IPv4 n'étant pas natif chez Free/FreePro autant l'éviter le plus possible.

Deux autres membres sur Github ont pu me confirmer qu'ils n'arrivent pas non plus à monter de tunnels IPSEC fiables à cause du blocage des protocoles entrants par la Freebox.

oui mais ce n'est pas la même problématique justement.

Ne pas pouvoir monter un tunnel (erreur/aucun trafic/port bloqué) et avoir un trafic bridé ou incohérent sont vraiment 2 sujets différents (sauf cas très rare).

on peut facilement tester le blocage avec traceroute sous FreeBSD.

pour la mtu ca se test facilement (cf commandes tracepath sous Linux, traceroute sous FreeBSD) est-ce que le tunnel pas au dessus d'IPv6 ou IPv4 ?

Mais c'est peut-être plutôt un problème de saturation/limitation du trafic UDP entre JN et OVH (a un époque OVH et Orange avait ce souci entre eux).

Un test avec iperf3 en UDP sera une bonne chose à faire pour voir le taux de perte (ou autre) par exemple et pour savoir si le problème est au niveau UDP ou au dessus.

J'utilise Wireguard (avec Tailscale) entre des machines derrière une Freebox Pro et des machines chez Online et d'autres derrière une Livebox Pro Fibre et aucun souci de débit de tunnel dans les 2 sens. J'ai plus de VPS chez OVH depuis l’incendie donc je ne peux tester avec OVH. Apres c'est du trafic UDP sur IPv6.

L'IPv4 n'étant pas natif chez Free/FreePro autant l'éviter le plus possible.

oui mais ce n'est pas la même problématique justement.

Ne pas pouvoir monter un tunnel (erreur/aucun trafic/port bloqué) et avoir un trafic bridé ou incohérent sont vraiment 2 sujets différents (sauf cas très rare).

on peut facilement tester le blocage avec traceroute sous FreeBSD.

Quelques tests ont étés fait avec iperf, mais aucune perte de paquets à été remarqué d'un côté comme de l'autre (0%).
Nous obtenons sur la Freebox : 800Mbps Upload et 1200Mbps download.

Par contre en TCP, ce ne sont pas du tout les mêmes débits. (voir capture d'écran)

Il règne donc une incompréhension concernant le débit visualisé par envoi avec le protocole SMB sur le port 445, nous obtenons 500ko/s (OVH --> FREEBOX)
Auriez-vous d'autres tests à nous faire faire pour comprendre d'où vient le problème ?

Actuellement, le tunnel IPSEC est monté sur de l'IPv4, nous allons essayer avec de l'IPv6 quand OVH l'activera sur notre infrastructure. (Ticket ouvert)

Juste pour être sur, vous n'avez pas testé le sens OVH --> Freepro alors que pour nous, c'est ce sens-là qui pose problème.

Nous venons de tester l'envoi par FTP plutôt que par SMB et nous avons des débits quasiment identiques.



Client OVH - Serveur Free :

TCP : iperf.exe -c client_OVH https://nsa40.casimages.com/img/2021/06/18/210618051433873512.png

UDP : iperf.exe -c client_OVH -u -b 2000M https://nsa40.casimages.com/img/2021/06/18/210618051433956608.png


Client Free - Serveur OVH :

TCP : iperf.exe -c client_Free https://nsa40.casimages.com/img/2021/06/18/210618050900833826.png

UDP : iperf.exe -c client_Free -u -b 2000M https://nsa40.casimages.com/img/2021/06/18/210618050652932609.png


"Le --get-server-output n'affiche rien de plus"






 

attention avec Windows, iperf3 n'est pas très fiable. surtout la 3.1.3 qui est trop ancienne et buggée en UDP.

ce site tient une version a jour pour Windows : https://files.budman.pw/ (3.10.1 la derniere donc)

Le test UDP indique d'un coté ce que ca envoi mais pas forcement ce qui est reçu. Il faut attendre la fin du test pour voir le rapport de reception.


dans le sens OVH -> Freepro j'ai pas de probleme en UDP.

Mais avoir des pertes/out-of-order dans un sens peut fortement impacter un trafic IPSEC dans l'autre sens si les acquirements sont perdus ou doivent être retransmis car n'arrivant pas dans l'ordre.


et ps: c'est le trafic hors tunnel pas dans le tunnel qu'il faut tester (tester le chemin du tunnel).

@kgersen

Merci pour toutes ces informations, nous avons donc tester iperf depuis Pfsense avec et sans le tunnel IPSEC et TCP/UDP.

Merci pour votre aide.

TCP WITHOUT IPSEC :
https://nsa40.casimages.com/img/2021/06/21/210621063717321230.png

UDP WITHOUT IPSEC :
https://nsa40.casimages.com/img/2021/06/21/210621063717833336.png

TCP WITH IPSEC :
https://nsa40.casimages.com/img/2021/06/21/210621063717221803.png

UDP WITH IPSEC :
https://nsa40.casimages.com/img/2021/06/21/210621063717582204.png


- Constatation :

Sans IPSEC et TCP :

GDD --> OVH = 13Mo/s = PAS OK
OVH --> GDD = 13 Mo/s = PAS OK

Sans IPSEC et UDP :

GDD --> OVH = 77 Mo/s = OK
OVH --> GDD = 111 Mo/s = OK

Avec IPSEC et TCP :

GDD --> OVH = 12Mo/s = Normal en vue du débit sans IPSEC
OVH --> GDD = 0,35Mo/s = PAS OK

Avec IPSEC et UDP :

GDD --> OVH = 75 Mo/s = OK
OVH --> GDD = 107 Mo/s = OK