Bonjour,

J’ai un problème de connectivité interne dans mon LAN depuis que j’ai remplacé une livebox par une Freebox Pop.
Et j’aimerai de l’aide pour debugger svp, car je suis un peu perdu là…

Basiquement, on dirait que la Freebox ne fait pas correctement son rôle de switch/bridge (L2 donc) entre le wifi et les ports ethernet dans certains cas (cf ci-dessous).
Et cela semble notamment bloquer les (réponses) ARP, et donc tout le trafic IP.

Globalement, j’ai une Freebox et 3 machines qui entrent en jeu:
0) Freebox Pop (wifi 7) toute neuve
A) NAS (avec des containers, A2) branché par cable ethernet
B) Client “fixe” branché aussi => OK pour joindre le nas+container ✅
C) Client “mobile” en wifi => problème partiel pour joindre le container ❌

Comme visible sur le schéma global des flux (cf tests ICMP décrit plus tard)

• la plupart des flux marchent bien ✅, mais il y a un flux qui ne marche pas: depuis un client wifi (C) vers les container du NAS (A2) ❌
• Aucun composant n’est clairement défectueux, car ils ont tous au moins un flux qui fonctionne, le souci est donc une combinaison de facteurs (plus difficile à trouver)
• NB: mon réseau n’est pas plus compliqué que dessiné: pas de switch matériel en plus, juste le NAS + le container + clients branchés directement sur la freebox, un seul subnet, pas de VLAN, le seul aspect un peu “exotique” est l’usage des containers sur le NAS

NB: je vais ajouter plus d’infos dans les posts suivants

Est-ce que vous avez des idées à me suggérer pour résoudre ce soucis ?
Merci d’avance

Mon analyse et infos importantes:

• Il ne s’agit pas d’une “simple” instabilité du wifi (cf test du ping google très stable, et test refait sur plusieurs machines), ca semble plus profond
• Au début (et plus maintenant, sans que je sache pourquoi), le soucis disparaissait *temporairement* quand je redémarrais le container sur le NAS => un cache ARP ou de bridge qui se remplit/vide pas correctement ?
• Lors du test KO (cf détails ARP), le client wifi (C) ne découvre pas l’adresse mac du container (A2), cf le “incomplete”, mais le container a bien obtenu la mac du client wifi (cf: mac avec “zz”) => traffic coupé de façon asymétrique ?
• Le même setup fonctionnait normalement quand j’avais une livebox au lieu de la freebox, avec les mêmes config de réseau partout (client, nas, container). Donc j’ai tendance à penser que le souci vient de la Freebox, mais c’est aussi potentiellement plus compliqué (combinaison d’un truc pas standard du côté de mon NAS+container + un comportement différent de la FB vs la livebox)

Différentes choses que j'ai déjà testées:

• différents hardware & OS clients pour le client en wifi (2 macbooks, 2 androids, 1 mini-pc linux) =>  tous KO pareil
• avec le wifi 2ghz vs 5ghz (cf 2 ssids différents configurés sur la FB) => KO pareil
• simplifier un peu en éteignant les autres containers et en garder qu’un seul => KO pareil
• redémarrer la freebox, le nas et les client wifi => KO pareil
• changer le NAS de port sur la freebox, j’ai testé les 3 => KO pareil
• le blocage semble être au niveau ARP, qui sont des trames de petite taille, donc j’élimine les soucis de MTU

=> le critère différenciant est vraiment: client en wifi => ❌, alors que en ethernet => ✅

Infos supplémentaires sur le NAS:

• Hardware: un serveur “fait maison”: une carte mère supermicro avec IPMI (sur le port partagé qui fait tout)
• Software: TrueNAS Core (FreeBSD), et les containers sont des jails FreeBSD
• Réseau: une interface “vnet” (une interface virtuelle avec une mac dédiée) par container et un bridge virtuel global (bridge0 avec dedans: igb0 vers freebox et vnet0.x pour le container)
• Firewall: je n’ai mis aucune règle sur le NAS

La freebox:

• Firmware: 4.8.16
• Matériel : Freebox v8 (r1)
• FTTH Pon, ip v4 “full stack”
• Mode: routeur classique

C'est comme ton système de container (docker ?) ?, pourquoi tu as une ip différente (.14) de l'hote (.11) et surtout 2 MAC différentes ?!

Ce sont des jails Freebsd, avec chacune une interface réseau dédiée (vnet) + un bridge.
cf mes notes "Infos supplémentaires sur le NAS" dans mon post précédent.

J'ai fait ce choix de vnet, car une des jails contient un VPN wireguard qui nécessite une interface dédiée pour le routage+nat du trafic des clients vpn.
Mais cette jail est éteinte lors des tests (pour simplifier) et le soucis est toujours présent sur la jail "www" qui est bcp plus basique, et aussi: tout fonctionnait bien avant le remplacement Livebox->Freebox.

La doit y a voir un systeme de proxy arp pour faire porter ta 2eme IP sur la même interface physique que la 1ere (ou alors c'est du macvlan?) , ca peut être l'origine du souci avec les clients wifi si la freebox filtre (par sécurité) des réponses arp qui ne viennent pas de la bonne mac: (c'est une hypothese).

Il ne devrait pas y avoir de proxy arp en théorie (sauf s'il a été mis par TrueNas sans que je le sache).
En pratique, la mac du container (telle que vue par le client fixe qui marche) est bien celle portée par l'interface dédiée du container, donc il ne semble pas y avoir de proxy-arp, mais vraiment juste un bridge L2 simple.

D'ailleurs, la freebox voit plusieurs "équipements" sur le port ether du NAS: chacun avec une mac dédiée, cf screenshot à la fin.
Donc, vu de la freebox, le NAS devrait se comporter comme un switch simple qui agrège plusieurs devices.

Merci pour ton aide 

hum c'est donc comme si tu avais un switch (S) en cascade sur le freebox avec derriere le nas et ses containers.

C'est exactement ça !

il faut regarder si possible la table des @ mac apprise par ton bridge S:

Bonne idée, voici le résultat:
### Juste après le client wifi ❌
nashome# ifconfig bridge0 addr
14:10:zz:zz:zz:cb Vlan1 igb0 1200 flags=0<>           # client wifi
38:c9:zz:zz:zz:3b Vlan1 igb0 1151 flags=0<>          # client fixe
3c:ec:xx:xx:xx:53 Vlan1 igb0 1193 flags=0<>         # nashome-ipmi
3e:ec:yy:yy:yy:b6 Vlan1 vnet0.7 1178 flags=0<>     # container
[...]

### Juste après le client filaire ✅ :
nashome# ifconfig bridge0 addr
14:10:zz:zz:zz:cb Vlan1 igb0 21 flags=0<>             # client wifi
38:c9:zz:zz:zz:3b Vlan1 igb0 1200 flags=0<>          # client fixe
3c:ec:xx:xx:xx:53 Vlan1 igb0 1177 flags=0<>         # nashome-ipmi
3e:ec:yy:yy:yy:b6 Vlan1 vnet0.7 1184 flags=0<>     # container
[...]
=> tout semble ok dans les 2 cas: les macs des clients & du container sont connus et sur le bon port

et il faudrait détailler plus ta capture des reply arp sur le nas :
si ca se trouve ce reply ne sort pas de S ?

D'après les tcpdump ci-dessous, la réponse arp sort bien du bridge S, car on la voit sur un `tcpdump -i igb0` (igb0 étant l'interface physique du NAS, donc "après" le bridge dans le sens "container->wifi")

et la comparer avec la capture d'un  reply dans le cas du client fixe pour voir s'il y a une différence susceptible d'etre filtré par la freebox.

Effectivement, c'est une idée intéressante ! Voici ce que j'ai pu observer:
NB: le même client pour les 2 tests ici (un macbook), histoire de minimiser les différentes autres que "wifi vs filaire"
### Client wifi ❌:
nashome# tcpdump -i igb0 -nn -vvve arp
tcpdump: listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:12:02.882851 14:10:zz:zz:zz:cb > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 64: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.14 tell 192.168.8.227, length 50
21:12:02.882961 3e:ec:yy:yy:yy:b6 > 14:10:zz:zz:zz:cb, ethertype ARP (0x0806), length 46: Ethernet (len 6), IPv4 (len 4), Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 32

### Client filaire ✅ :
nashome# tcpdump -i igb0 -nn -vvve arp
tcpdump: listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:12:58.783977 38:c9:zz:zz:zz:3b > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.14 tell 192.168.8.235, length 46
21:12:58.784013 3e:ec:yy:yy:yy:b6 > 38:c9:zz:zz:zz:3b, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 28
=> les tailles (à la fois des requêtes et des réponses) sont un peu différentes entre wifi & filaire ,

Je ne sais pas encore pourquoi, ni si c'est important pour mon problème.
Je vois juste que c'est différent.

ps: as-tu essayé avec un autre client wifi qu'un produit Apple ?

Nouveau test qui montre plus précisément le soucis (sans avoir besoin de relire avant)
Je vais comparer 3 cas:

• Client wifi sur Livebox => ping vers container OK ✅
• Client wifi sur Freebox => ping vers container KO ❌
• Client filaire sur Freebox => ping vers container OK ✅

NB: pour le 1er test, j'ai juste remis la Livebox à la place de la freebox (donc branché le NAS dessus, et changé de réseau wifi sur le client) et rien changé d'autre (les 2 box ont le même subnet pour le LAN: 192.168.8.1/24, et c'est bien le même client de test partout: mon macbook wifi ou avec adapteur ethernet, et je fais un: `sudo arp -d  192.168.8.14; ping -c 1 192.168.8.14`)

Et cette fois-ci, je regarde les tcpdump des 2 cotés: à la fois client & NAS (pour voir la requête ARP avant et après la box).

# Client wifi sur Livebox (✅) :
macbook$ sudo tcpdump -i en0 -nn -vvve arp
20:59:28.910864 14:10:zz:zz:zz:cb > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.14 tell 192.168.8.103, length 28
20:59:28.914382 3e:ec:yy:yy:yy:b6 > 14:10:zz:zz:zz:cb, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 46
nashome# tcpdump -i igb0 -nn -vvve arp
20:59:28.950654 14:10:zz:zz:zz:cb > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.14 tell 192.168.8.103, length 46
20:59:28.950743 3e:ec:yy:yy:yy:b6 > 14:10:zz:zz:zz:cb, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 28

### Client wifi sur Freebox (❌):
macbook$ sudo tcpdump -i en0 -nn -vvve arp
21:01:59.338379 14:10:zz:zz:zz:cb > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.14 tell 192.168.8.227, length 28
[pas de réponse]
nashome# tcpdump -i igb0 -nn -vvve arp
21:01:59.377399 14:10:zz:zz:zz:cb > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 64: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.14 tell 192.168.8.227, length 50
21:01:59.377490 3e:ec:yy:yy:yy:b6 > 14:10:zz:zz:zz:cb, ethertype ARP (0x0806), length 46: Ethernet (len 6), IPv4 (len 4), Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 32

### Client filaire sur Freebox (✅) :
macbook$ sudo tcpdump -i en3 -nn -vvve arp
21:05:06.928044 38:c9:zz:zz:zz:3b > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.14 tell 192.168.8.235, length 28
21:05:06.928605 3e:ec:yy:yy:yy:b6 > 38:c9:zz:zz:zz:3b, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 46
nashome# tcpdump -i igb0 -nn -vvve arp
21:05:06.960290 38:c9:zz:zz:zz:3b > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.14 tell 192.168.8.235, length 46
21:05:06.960415 3e:ec:yy:yy:yy:b6 > 38:c9:zz:zz:zz:3b, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.8.14 is-at 3e:ec:yy:yy:yy:b6, length 28

=> la requête ARP fait bien la même taille au départ (observée sur le macbook) dans les trois cas, donc ok jusque là (le client me fait rien de mal) ✅
=> mais elle arrive "plus grosse" (+4 octets) sur le NAS uniquement dans le cas wifi+Freebox ❌, alors que ok dans les 2 autres cas
=> bug sur la freebox en fonction de la mac de destination quand c'est en wifi ?