pfSense sur Virtio : le TCP se bloque jusqu’à ce que l’offload soit désactivé

Un client signale que le tunnel se connecte, qu’un ping répond, que la page de connexion se charge, puis que le transfert se fige au même point à chaque tentative. Ce schéma dit déjà beaucoup : la joignabilité fonctionne et le débit soutenu non. Avant d’ouvrir le pare-feu, déterminez si le VPN participe réellement à la panne. Faites passer du TCP volumineux par la même passerelle sans tunnel sur le chemin ; si cela se fige aussi, OpenVPN n’a jamais été impliqué.

Un invité pfSense doté d’une carte réseau virtio a de très bonnes raisons d’échouer exactement de cette façon.

Les petits paquets passent, le TCP volumineux se bloque

Les handshakes, les réponses DNS et les échos ICMP sont petits et passent généralement. Les transferts soutenus forcent l’invité à segmenter, et c’est là qu’un chemin d’offload endommagé se manifeste. La panne n’est pas forcément symétrique : le trafic sortant peut être propre tandis que l’entrant se perd, ou l’inverse, si bien qu’un utilisateur peut se connecter puis se bloquer sur la première grosse réponse. Comme le même client fonctionne via une autre passerelle, la responsabilité retombe sur le composant le plus récent.

Testez donc la passerelle sans le tunnel. Un téléchargement de LAN vers WAN assez gros pour durer quelques secondes suffit, et il doit être fait avant tout changement de réglage pour que la comparaison ultérieure ait un sens.

Ce que l’offload promet vraiment

virtio est paravirtualisé : l’hôte et l’invité partagent le travail, l’hôte annonce des capacités de somme de contrôle et de segmentation et attend que l’invité termine ce qu’il a commencé. Si la pile de l’invité ne le fait pas, les trames partent avec des sommes de contrôle incomplètes ou sont rejetées par l’hôte. Une E1000 émulée offre un modèle plus simple et plus lent où le problème disparaît sans la moindre modification de pfSense. La négociation des capacités se fait par périphérique, ce qui explique pourquoi un invité tourne pendant des mois alors que son jumeau reconstruit échoue dès le premier jour.

L’ensemble négocié dépend de la version de l’hyperviseur et du modèle de carte réseau choisi, pas seulement de la configuration importée.

Une case à cocher suffit à garder virtio

Dans l’interface pfSense, Système puis Avancé puis Réseau contient une case nommée Désactiver l’offload matériel de la somme de contrôle. La cocher fait calculer les sommes de contrôle par logiciel dans l’invité, ce qui correspond à ce que la pile FreeBSD derrière pfSense attend d’un périphérique paravirtualisé. Deux options liées sur la même page couvrent l’offload matériel de segmentation TCP et l’offload matériel de grande réception. Recourez-y lorsque les handshakes réussissent mais pas les transferts volumineux.

Laissez la carte réseau en virtio pendant la modification. Passer à E1000 brûle du processeur sur chaque paquet pendant toute la vie de la VM et dissimule le problème de configuration à quiconque hérite de l’hôte, ce qui est un pire compromis qu’un chemin de données un peu plus lent mais prévisible.

Mesurez le coût que vous venez d’accepter

Le calcul logiciel des sommes de contrôle déplace du travail dans l’invité, alors mesurez le débit ensuite au lieu de supposer que cela ne coûte rien. Sur une petite VM, la pénalité est réelle, mais elle est visible et stable, contrairement à une perte silencieuse. Comparez les compteurs d’erreurs de l’interface et le journal du noyau de l’invité avant et après. Un hyperviseur qui filtre le pont est une panne distincte avec d’autres preuves, et aucun indicateur d’offload ne la guérira.

Ne changez qu’une chose par test et notez le chemin de menu, la case cochée et le nombre mesuré. Quiconque affrontera le prochain invité reconstruit voudra les trois.

D’autres pare-feu basés sur BSD exposent un contrôle équivalent dans leurs propres réglages d’interface, si bien que le raisonnement se transpose même quand le chemin de menu ne le fait pas.