Après une mise à jour vers pfSense 2.7.2‑RELEASE, votre débit s’effondre autour de 90 Mb/s et la connexion tombe ? Ce guide pas‑à‑pas explique les causes probables (offload, passerelle, shaping, MTU) et fournit une procédure fiable pour restaurer 600–700 Mb/s stables.
Ralentissement du débit et coupures après l’installation de pfSense 2.7.2‑RELEASE
Vue d’ensemble du problème
- Avant pfSense : 600–700 Mb/s stables.
- Après pfSense : ~90 Mb/s et déconnexions fréquentes.
- Symptôme annexe : la passerelle par défaut attribuée dynamiquement change ; même lorsqu’elle est forcée en statique, l’entrée disparaît au bout de quelques jours.
Causes possibles relevées ou implicites
| Domaine | Vérifications essentielles |
|---|---|
| Interfaces réseau | Câble/port en Gigabit ? Négociation duplex/auto ? Pilote NIC à jour ? |
| Configuration pfSense | Aucune règle de traffic‑shaping ou Limiters activée ? Pas de QoS mal réglée ? |
| Passerelles & routage | Option « Allow default gateway switching » désactivée ? Passerelle statique définie via System › Routing › Gateways et non seulement via DHCP ? |
| DHCP/Conflicts | Attribution d’adresse sans chevauchement ? Bail DHCP WAN correct ? |
| MTU & fragmentation | MTU cohérente (souvent 1500, sauf PPPoE/VPN) ? |
| Logs & santé système | Journaux système, Gateways et Status › Interfaces pour erreurs (flapping, packet loss) ? |
| Mise à jour | Correctif 2.7.2‑pX ou branche 23.09‑LTS disponible ? |
Procédure de diagnostic rapide (10 minutes)
- Bypass express : branchez un PC en direct sur le modem/ONT et faites un speedtest filaire. Si vous retrouvez 600–700 Mb/s, le goulet est côté pfSense.
- Vitesse/duplex : sur le switch et sur pfSense, forcez 1000Base‑T Full Duplex et remplacez le câble (cat 5e/6).
- Offloads : dans System › Advanced › Networking, cochez « Disable hardware checksum offload » et « Disable large receive offload », sauvegardez et retestez.
- Passerelle : créez une Gateway WAN statique (System › Routing › Gateways), cochez « Default ». Dans System › Routing › Settings, décochez « Allow default gateway switching ».
- Limiter/Shaper : supprimez toute règle associée à des Limiters (pipes à 100 Mb/s) ou à l’ALTQ/HFSC si non utilisé.
- MTU : vérifiez l’MTU effective (PPPoE ≈ 1492). Ajustez si la fragmentation apparaît.
- Reboot & test : redémarrez pfSense, puis testez depuis un poste filaire avec
iperf3et un speedtest navigateur.
Plan de remédiation détaillé
Valider le matériel
- Forcer provisoirement la vitesse/duplex à 1 Gbit Full des deux côtés (switch ↔ pfSense). Une auto‑négociation capricieuse se traduit souvent par ~100 Mb/s plafonnés.
- Changer de câble/port. Les faux‑contacts ou un câble cat 5 vétuste provoquent des erreurs et des renégociations.
- Regarder les compteurs d’erreurs dans Status › Interfaces : Input/Output errors, collisions, flaps (liens qui montent/descendent).
Désactiver les optimisations problématiques
Sur certaines cartes (notamment Realtek ou Broadcom), les offloads matériels posent problème sous FreeBSD/pfSense.
- Allez dans System › Advanced › Networking.
- Cochez : « Disable hardware checksum offload », « Disable large receive offload » (LRO), éventuellement « Disable TCP segmentation offload » (TSO) selon les symptômes.
- Sauvegardez, appliquez, retestez le débit.
Note : la charge CPU peut augmenter légèrement, mais la stabilité et le débit s’améliorent souvent nettemement.
Contrôler le routage et la passerelle
- Créer/forcer la passerelle WAN statique : System › Routing › Gateways → Add, sélectionnez l’interface WAN, saisissez l’IP de la passerelle fournie par l’opérateur, cochez « Default ». Renseignez un Monitor IP (8.8.8.8 ou une IP du FAI) pour dpinger.
- Désactiver le basculement automatique : System › Routing › Settings → décochez « Allow default gateway switching ». Cela empêche pfSense de remplacer la route par défaut par une route éphémère lorsque le monitoring pense que la GW est instable.
- Stabiliser dpinger : dans la passerelle, Advanced, ajustez les seuils (latency/loss) et cochez « Disable Gateway Monitoring Action » si vous préférez que les états ne soient pas tués automatiquement lors d’une brève perte.
- État de la table de routage : Diagnostics › Routes : vérifiez qu’une unique
defaultpointe vers votre GW. L’absence dedefaultou une link‑local IPv6 par défaut à la place sont des signaux d’alarme.
Examiner les règles de firewall et le traffic shaping
- Limiters/Dummynet : dans Firewall › Traffic Shaper ou Firewall › Rules, l’onglet « Advanced Options » peut lier un In/Out pipe à vos règles. Supprimez ou désactivez tout pipe à 100 Mb/s résiduel.
- ALTQ/HFSC : si vous n’utilisez pas l’ALTQ (interfaces non compatibles, règles vides), désactivez le shaper. Un profil mal calibré peut brider le WAN.
- Règles flottantes : inspectez les « Floating rules » qui s’appliquent en premier. Un Match avec limiteur affecte tout le trafic sortant.
Vérifier l’MTU et le Path MTU Discovery
Une MTU inadéquate (PPPoE, tunnels) force la fragmentation ou le rejet de paquets, ce qui ressemble à des coupures.
| Technologie | MTU typique | Remarques |
|---|---|---|
| Ethernet direct | 1500 | Valeur par défaut la plus courante |
| PPPoE | 1492 | En raison de l’en-tête PPPoE (8 octets) |
| GRE / VPN IPsec tunnel mode | 1400–1476 | Dépend des en‑têtes chiffrés/encapsulés |
| VLAN (802.1Q) | 1500 (si « baby‑giants ») | Certains équipements exigent 1508 en interne |
Test rapide (Windows) : trouvez la plus grande taille qui passe sans fragmentation :
ping -f -l 1472 8.8.8.8
Test rapide (Linux/*BSD) :
ping -M do -s 1472 8.8.8.8
Si 1472 échoue, diminuez par paliers (1464, 1452…). L’MTU WAN = taille réussie + 28 octets d’en‑têtes IP/ICMP (ex. 1472 → MTU 1500).
Mettre pfSense et les pilotes à jour
- Appliquez les mises à jour proposées (System › Update). Sur 2.7.2, installez les révisions pX disponibles si proposées.
- Redémarrez pfSense après mise à jour et surveillez l’évolution sur quelques jours. Si la GW « s’évapore » ensuite, suspectez un bug corrigé dans une révision ultérieure ou un service tiers (dpinger) trop agressif.
Surveiller et tracer
- Status › Monitoring : graphez débit WAN, latence et packet loss.
iperf3LAN→LAN : confirmez que le goulot est sur le WAN, pas dans votre LAN interne.- Status › System Logs › Gateways : recherchez des cycles « down/up » (flapping) corrélés à vos coupures.
Diagnostics en ligne de commande (console/SSH)
Depuis le shell de pfSense (option 8) :
# Vitesse et erreurs des interfaces
ifconfig -m
netstat -I igb0 -w 1 # remplacez igb0 par votre interface
# Table de routage (vérifier la route par défaut)
netstat -rn
route -n get default
# États du firewall (utile après bascule de GW)
pfctl -si
pfctl -ss | wc -l
# Résolution DNS et latence vers la passerelle
ping -c 10
traceroute 8.8.8.8 Si la default a disparu, ajoutez‑la provisoirement (test) :
route add default <GW_IP>
Si cela rétablit Internet, revenez dans l’interface Web pour définir durablement la passerelle par défaut et ajuster dpinger.
Cas fréquents et correctifs ciblés
Cartes Realtek bridant à ~100 Mb/s
Symptômes : débit plafonné à ~90–100 Mb/s, erreurs RX/TX, remontées de lien (flaps). Correctifs :
- Activez les options « Disable … offload » (voir plus haut).
- Remplacez le NIC par un modèle Intel (i210‑AT, 82574L, i350). Ces chipsets offrent un support FreeBSD robuste et un buffer plus généreux.
PPPoE : MTU incorrecte et passerelle « volatile »
Symptômes : débit variable, sites injoignables, route par défaut qui bascule sur une IPv6 link‑local. Correctifs :
- Réglez l’MTU WAN à 1492 (ou détectez la bonne valeur via ping DF).
- Dans la passerelle PPPoE, fixez un Monitor IP public stable (évitez l’IP de la GW si elle ne répond pas à l’ICMP).
- Désactivez « Allow default gateway switching » et, au besoin, cochez « Disable Gateway Monitoring Action » pour empêcher la purge d’états lors d’une micro‑coupure.
Multi‑WAN non intentionnel ou box opérateur en double NAT
Si votre box n’est pas en mode bridge, pfSense obtient une adresse privée (RFC1918) sur le WAN, ce qui fausse le monitoring de passerelle et le PMTUD.
- Activez le mode bridge côté box si possible, ou configurez DMZ vers l’IP WAN de pfSense.
- Vérifiez que System › Routing › Gateway Groups ne contient pas un groupe par défaut involontaire.
VLAN et switch limitant à 100 Mb/s
Si le port du switch négocie en 100Base‑TX suite à une configuration VLAN ou à l’EEE, vous verrez ~95 Mb/s max.
- Désactivez l’EEE/Green Ethernet sur le port WAN.
- Forcez 1000 Mb/s Full sur le port et testez un autre port.
Modèle d’incident : de la panne à la résolution
- Confinement : désactiver temporairement tout shaper/limiter. Conserver uniquement les règles PASS/OUT nécessaires.
- Observation : surveiller dpinger (perte/latence) sur 15 min. Si la GW clignote down/up, suspecter la boucle de basculement de passerelle.
- Hypothèse A (couche 1/2) : erreurs, 100 Mb/s → câbles/ports/NIC.
- Hypothèse B (couche 3) : route par défaut disparaît → paramétrage passerelle/dpinger.
- Hypothèse C (couche 4/7) : débit plafonné sans erreurs → offloads/limiters/MTU.
- Action : appliquer correctifs ciblés (offload OFF, passerelle statique, shaper OFF, MTU ajustée), puis valider par tests reproductibles.
Tests reproductibles (ne pas se fier qu’au navigateur)
- LAN ↔ LAN local :
iperf3 -ssur un PC A,iperf3 -c <ip_A> -P 4 -t 20depuis un PC B. Vous devez atteindre > 900 Mb/s en Gigabit. Si ce test échoue, le goulet est interne au LAN. - LAN → Internet :
iperf3vers un serveur public/privé de confiance (si disponible), ou des speedtests CLI. Comparez avant/après chaque changement. - Reverse :
iperf3 -Rpour tester le sens descendant.
Tableau de contrôle : ce qu’il faut vérifier
| Point de contrôle | Attendu | Action si non conforme |
|---|---|---|
| Négociation WAN | 1000Base‑T Full, zéro erreur | Forcer 1G Full, changer câble/port/NIC |
| Offloads | Checksum/LRO/TSO désactivés | Désactiver dans Advanced › Networking |
| Passerelle par défaut | Route default unique & stable | GW statique + Monitor IP, gateway switching OFF |
| dpinger | Latence stable, pertes < 1 % | Ajuster seuils, « Disable monitoring action » si nécessaire |
| Traffic Shaper | Aucun pipe limitant à 100 Mb/s | Supprimer/neutraliser les limiters et règles flottantes |
| MTU | 1500 (ou 1492 PPPoE) | Ajuster MTU WAN, valider via ping DF |
| Mises à jour | 2.7.2 + correctifs pX | Appliquer System › Update |
Stabiliser définitivement la passerelle
Le symptôme « la passerelle statique disparaît au bout de quelques jours » indique souvent un enchaînement : dpinger marque la GW « down », l’option « Allow default gateway switching » remplace la route par défaut, puis la configuration ne rétablit pas la route d’origine.
- Fixer la GW (System › Routing › Gateways) et la déclarer Default.
- Désactiver « Allow default gateway switching » (System › Routing › Settings).
- Choisir un Monitor IP qui répond (ex. DNS public), éviter les IP de GW qui filtrent l’ICMP.
- Option avancée : cochez « Disable Gateway Monitoring Action » si vous préférez que pfSense n’abatte pas les états au moindre faux‑positif.
- Surveiller : Status › System Logs › Gateways. Si le flapping cesse, la route restera en place.
Bonnes pratiques de performance pfSense (> 500 Mb/s)
- CPU : au moins 2 cœurs ≥ 2 GHz (Intel 64) pour tenir 600–700 Mb/s avec NAT/Firewall.
- NIC : privilégier Intel (i210‑AT, i350, 82574L). Éviter les Realtek low‑cost pour des charges soutenues.
- Règles épurées : supprimez les règles dormantes, consolidées dans des alias plutôt que des doublons.
- Logs utiles : activez uniquement ce qui est nécessaire (éviter un sur‑logging qui sature l’I/O sur de vieux SSD/CF).
FAQ rapide
Q : Pourquoi je plafonne à ~95 Mb/s alors que j’ai un lien 1G ?
R : C’est typique d’une interface négociée en 100Base‑TX (câble, port, EEE) ou d’un Limiter laissé à 100 Mb/s.
Q : Dois‑je laisser les offloads désactivés définitivement ?
R : Oui si votre matériel se comporte mieux ainsi. Sur des NIC Intel récents, vous pouvez tester un ré‑activation partielle (TSO ON, LRO OFF) et mesurer.
Q : La route par défaut disparaît encore au bout de quelques jours !
R : Vérifiez que l’option « Allow default gateway switching » est bien désactivée, que le Monitor IP répond, et que Disable Gateway Monitoring Action est activée si des faux‑positifs persistent.
Q : Le navigateur m’annonce 300 Mb/s alors que iperf3 montre 600 Mb/s.
R : Certains speedtests sont limités par le serveur à l’instant T. Utilisez plusieurs serveurs/tests et comparez.
Exemple de séquence « de zéro à stable »
- Remplacer le câble WAN, forcer 1G Full sur le switch.
- pfSense : désactiver offloads, redémarrer.
- Créer GW WAN statique + Monitor IP, désactiver « Allow default gateway switching ».
- Supprimer tout Limiter ou shaper inutile.
- Ajuster MTU (1492 si PPPoE), valider via ping DF.
- Mettre à jour pfSense (2.7.2‑pX si proposé) et rebooter.
- Surveiller 48–72 h : plus de coupures ni de bascule de passerelle ; débit > 600 Mb/s.
Annexe : commandes et écrans clés
- Vérifier la négociation : Status › Interfaces → « Media ». Attendu : 1000Base‑T Full.
- Trafic par interface : Status › Monitoring › Traffic (interface WAN) : pointes cohérentes durant le test.
- dpinger : System › Routing › Gateways → colonne « RTT/LOSS » stable.
- Table des routes : Diagnostics › Routes : une seule ligne
default.
Conclusion
Dans la majorité des cas, un débit limité à ~90–100 Mb/s après passage à pfSense 2.7.2 et des coupures viennent d’un trio bien connu : offloads matériels capricieux, route par défaut instable (gateway switching/dpinger) et shaping/MTU mal alignés. En appliquant la méthode ci‑dessus — validation matérielle, désactivation des offloads, passerelle statique avec monitoring maîtrisé, suppression de tout shaping involontaire puis vérification MTU — vous devriez retrouver vos 600–700 Mb/s stables et une session WAN robuste.
Astuce finale : notez chaque changement et refaites systématiquement les tests (iperf3 + speedtest). La reproductibilité est votre meilleure alliée pour isoler la cause réelle et éviter les régressions ultérieures.