On dirait plutôt que les RST correspondent aux SYN ACK, non ?

Je suis aussi en 66.0.5 depuis hier, mais chez moi pas de SYN ACK,  juste un gros paquet de SYN (comme d'hab) puis les RST...  Virtualbox est également installé et non utilisé.

Maintenant que j'y pense, c'est peut-être pour ça que j'ai de temps en temps des alertes google qui me bloquent en détectant un fort trafic, comme si j'étais catégorisé hébergeur. Que je me suis dit plusieurs fois : ça y est il a pété un câble... 

Ah, avec cette syntaxe, on y voit plus clair, dans la capture que je viens de faire, y'a un mélange des deux : SYN puis RST et SYN-ACK/RST.

Je vais tester le 4.18 a tout hasard, bien que j'y crois pas trop...

A noter que sur mes deux PC, VirtualBox 6.0.6 est installé (mais non utilisé au moment où j'ai fait la capture)
Je me demande si le module kernel installé par VirtualBox pourrait avoir un impact.

Côté kernel il y a :
 - vboxnetflt : bridge, à tester (sur un bridge les VM ont des IP différentes, mais on ne sait jamais)
 - vboxnetadp : host-only, à priori ce n'est pas ça
 - le processus VBoxNetNAT (comme il est en setuid, peut-être qu'il ouvre directement les interfaces, et répond à certains paquets directement)

Virtualbox n'a rien à voir dans l'histoire à priori.

Testé sur le portable HP  sous debian qui m'a servi pour les tests 4G, sans VB installé et y'a toujours des RST/SYN-ACK en plus de l'habituel.

Faut donc sans doute bien modifier des paramètres de la pile réseau.

Comme la capture est filtrée, je ne suis pas sûr, mais je vois deux cas :
 - "tcp.stream eq 2", "tcp.stream eq 6", "tcp.stream eq 7", "tcp.stream eq 8" qui ont probablement des échanges filtrés => mutiples RST à cause de la fermeture simultanée par les deux parties (j'ai aussi la même chose avec Fedora pour lafibre.info ou apache.org par exemple), à priori pas très grave
 - "tcp.stream eq 9" à tcp.stream eq 33" qui sont annulés tout de suite (et un seul RST) => je n'ai pas ça avec Fedora (donc à moins que ça vienne de ma configuration, il doit y avoir des différences côté Firefox/glibc/kernel, ou côté iptables)

Pour mieux caractériser le phénomène, j'ai mis en place deux pages web de test.

102 requêtes et 349Ko téléchargés : https://lafibre.info/site/citefibre/offres_premium_tvnumerique.htm
287 requêtes et 1784Ko téléchargés : https://lafibre.info/site/declic-telecom/www.declic-telecom.com/television.html

Ce sont des pages statiques, sans connexion et qui ne changent jamais, ce qui facilite l’investigation en enlevant des hypothèses.

Il faut juste vider le cache avant de charger une des pages.

Voici une capture de la page citéFibre quand tout se passe bien : 6 connexions TCP ouvertes, toutes utilisées, aucun reset, aucun paquet retransmis : 201905_ref_citefibre_firefox67_ubuntu1904.pcapng.gz
Le FAI utilisé est SFR câble 100 Mb/s.

Voici une capture de la page citéFibre un peu dégradé : il y a des paquetés envoyés en double et le serveur envoi deux reset à chaque fin de connexion, car il a reçu des paquets pour une connexion qu'il considère déjà fermée : 201905_ref_citefibre_firefox66_ubuntu1904.pcapng.gz
Le FAI utilisé est un opérateur d’entreprise avec un  plateforme de sécurité entre moi et Internet.

Dans les deux cas je suis connecté directement en Ethernet pour éviter les paquets perdu du WiFi.
Le système d’exploitation client est Ubuntu 19.04 dans les deux cas.
La version de Firefox n'est pas la même mais je ne pense pas que ce soit ça qui impacte le résultat.

Je n'arrive pas a reproduire les connexions TCP ouvertes par dizaines et les reset envoyé à tout va...

Tu arrives à reproduire la chose avec cette page statique après avoir vidé le cache ?

Il serait intéressant de savoir si le problème est résolut ou si tu n'a que des reset que sur SMF sur le forum (c'est le moteur du forum)

Les pages tests sont très proche : c'est le même serveur web qui répond, simplement le contenu est en statique ce qui permet de rendre la chose plus reproductible, vs contenu dynamique qui change a chaque appel.