Selon une IA, ce problème proviendrait de Docker en mode pont et de la combinaison choisie. Elle recommande de se passer de Docker pour le DHCP ou de configurer
Docker avec Macvlan/Ipvlan. À vérifier, je ne suis pas compétent dans le domaine.
On remarque que cette configuration est bien plus complexe que celle annoncée (figurant) dans le dépôt GitHub du projet.
Le responsable du projet nftables n'a pas non plus réussi à reproduire un bogue potentiel qui serait lié à la virtualisation (testé avec QEMU).
L'IA indique également que Docker gère du réseau, mais n’est pas conçu pour remplacer un routeur (mauvaise isolation).
Comme indiqué, ce souci intervient uniquement quand les drivers de la carte sont en VirtIO ou bcmgenet
(Raspberry donc sans virtu 
). Une fois les NIC passés en émulation E1000 ou Realtek, plus aucun souci.
La version Bouygues du projet embarque un correctif en phase de test qui semble corriger ce souci
(VM comme Bare metal tant que Debian 13 boot ça juste marche).
Le patch sera sûrement porté sur cette version même si cela ne semble pas bloquant chez Orange
(Dans le doute... autant le faire)
c'est pas tellement l'isolation Faut juste que ce soit pas ton accès internet "principal"
Parce que mettre un routeur et serveur DHCP profondément enfoui au sein d'un réseau local, dans une VM, pour jouer un rôle "top" sommet/centre de l'architecture tu te retrouves avec un problème d'oeuf et de poule et rendre plus compliquer l'administration de ton LAN avec des confs statiques de partout. Après tu peux faire des choses rigolote : 2 acces dans des VM et tu peux deplacer tes VM sur un autre site distant pour assurer l'internet de ta boite
Dans des labs où la majorité de l'infra est virtualisée, cela reste à débattre
Mes deux fibres arrivent directement au cul du serveur pour finir dans leur VM respective, chacune isolée dans un bridge avec un port en slave pour leur WAN et le LAN dans le bridge de mon réseau local.
Remplacer la LiveBox par un routeur