Pas de duplication côté routeur, ça doit donc être wireshark qui a un peu de mal.

Okay. hmmm... quand tu captures avec wireshark, tu captures bien uniquement sur l'interface physique (wlo0 ou enp2s0) ?

Yep

Bon, je change de tactique. La cohabitation vmware/virtualbox, ça va pas du tout.

Je me suis rappelé du réseau de milkywan à base de VxLAN, je me suis dit que j'allais faire pareil. Montage d'un tunnel entre une VM debian vers mon rapberry pi qui me sert de DHCP/DNS/serveur wireguard... et qui ressort sur le LAN. En plus j'ai déjà un bout de conf tout prêt d'autres essais. J'ai donc tenté le coup avec cette architecture :

Routeur principal --- LAN --- AP wifi - - - PC portable (hôte) -bridge- VM debian (VTEP) -bridge- /réseau interne/ --- pfsense
                                    |
                           Raspberry (bridge vxlan/eth0)
 
Sauf, qu'il y a un couac. Car je bridge eth0 sur le Rpi qui est l'unique interface par où tout sort. Ça doit faire une boucle (je suppose) et la connexion tombe.

J'ai fini par créer un VLAN supplémentaire bridgé avec le vxlan, que je fais remonter jusqu'à mon routeur principal et là fonctionne 

Par contre, j'ai un problème de MTU. Je suis obligé de la baisser à 1450 sur les VM, sinon le trafic ne passe pas en dehors des requêtes DNS et ICMP. Je n'arrive pas à trouver comment la faire s'adapter toute seule (ou que la debian fragmente) car de que j'ai lu la fragementation n'est pas supportée ni le PMTU car L2 et pas L3. Bizarrement, lorsque je l'avais essayé sur mon tunnel WG je n'ai rien fait de particulier (si ce n'est adapter la MTU du vxlan lui-même) et ça fonctionnait parfaitement je pensais donc que ça serait pareil ici.

Elle est à 1450 par défaut (qui est à priori la valeur en v4), mais visiblement ça ne suffit pas.  Ça fait plusieurs heures que je cherche des infos claires, sans succès.

La conf :

Rapspberry :
auto vxlan10
iface vxlan10 inet manual
        pre-up ip link add vxlan10 type vxlan id 10 dev eth0 remote 192.168.1.164 dstport 4789 || true
        up ip link set vxlan10 up
        down ip link set vxlan10 down
        post-down ip link del vxlan10 || true

auto br0
iface br0 inet manual
   bridge_ports eth0.40 vxlan10
5: eth0.40@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000
    link/ether b8:27:eb:ea:xx:xx brd ff:ff:ff:ff:ff:ff
8: vxlan10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master br0 state UNKNOWN group default qlen 1000
    link/ether 3e:6b:d2:c5:xx:xx brd ff:ff:ff:ff:ff:ff
9: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
    link/ether 3e:6b:d2:c5:67:73 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::3c6b:d2ff:fec5:6773/64 scope link
       valid_lft forever preferred_lft forever


VM debian  :
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp0s3
#iface enp0s3 inet dhcp
# This is an autoconfigured IPv6 interface
iface enp0s3 inet6 static
address 2a01:xx:xx:xx::164
netmask 64
gateway fe80::1a1e:78ff:xx:xx

auto enp0s8
iface enp0s8 inet manual

iface enp0s3 inet static
address 192.168.1.164
netmask  255.255.255.0
gateway 192.168.1.1

auto vxlan10
iface vxlan10 inet manual
        pre-up ip link add vxlan10 type vxlan id 10 dev enp0s3 remote 192.168.1.10 dstport 4789 || true
        up ip link set vxlan10 up
        down ip link set vxlan10 down
        post-down ip link del vxlan10 || true

auto br0
iface br0 inet static
   bridge_ports enp0s8 vxlan10
address 192.168.10.254
netmask 255.255.255.0


(enp0s8 est l'interface attachée au réseau interne)

root@debian:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:88:13:f5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.164/24 brd 192.168.1.255 scope global enp0s3
       valid_lft forever preferred_lft forever
    inet6 2a01:cb14:xx:xx::164/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe88:13f5/64 scope link
       valid_lft forever preferred_lft forever
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether 08:00:27:0f:c7:30 brd ff:ff:ff:ff:ff:ff
4: vxlan10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master br0 state UNKNOWN group default qlen 1000
    link/ether 36:8f:1f:51:88:ad brd ff:ff:ff:ff:ff:ff
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
    link/ether de:4a:81:2a:13:e5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.254/24 brd 192.168.10.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::dc4a:81ff:fe2a:13e5/64 scope link
       valid_lft forever preferred_lft forever

Merci

Bon, j'ai essayé d'augmenter la MTU pour que tout rentre, sauf que pas de bol, le chip du rasp ne supporte pas plus de 1500... Je suis donc condamné à faire avec.

C'est un raspi 4? À mon sens le chip le supporte mais le driver n'a pas ce qu'il faut pour changer la MTU du hardware.

Après recherche, j'ai vu qu'on pouvait faire du MSS clamping sur un bridge. J'ai donc essayé et ça fonctionne enfin sans toucher la MTU :

-charger le module : br_netfliter
-ajouter la règle iptables : iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1410

Tu es sur que tu as besoin de br_netfilter ? J'utilise nftables de nos jours, je sais plus trop.
Tu dois pouvoir limiter ta règle au traffic venant de l'interface vxlan, sans quoi tout le traffic forwardé par le raspi aura une MSS réduite.

Par contre, il faudra qu'on m'explique : je n'ai pas touché à l'IPv6, et celui-ci semble fonctionner sans soucis avec un MSS de... 1440. Comment est-ce possible ?

Seuls les hotes fragmentent en IPv6, les routeurs ne le font pas.
Lorsqu'un routeur voit passer un paquet trop gros pour la MTU de l'interface sortante, il le jette et renvoie un ICMP packet too big à la source.
La source enregistre une MTU plus faible dans son route cache et ré-émet les segments TCP avec une MSS réduite. C'est ce qu'on appelle PMTUd (Path MTU Discovery), mais il me semble que tu connais déjà et que je radote :-)

Donc pas besoin de hack de MSS en IPv6 (pour peu que les ICMP packet too big ne soient pas filtrés, et avant que tu demandes, si, si, en 2023, les DSI de grosses boites maintiennent dûr comme fer qu'il faut bloquer ICMP car "on se fait hacker avec", mais c'est de plus en plus rare...).

J'aimerais bien faire marcher PMTUd en v4, mais ça à l'air de coincer... ou il me manque des règles sur mon OWRT ? Sachant que tout est openbar sur le rasp et la debian.

Oublie PMTUd en IPv4... entre les équipements qui fragmentent même lorsque le flag DF est à 1 (rare, mais ca existe, surtout sur les firewalls), les routeurs qui n'envoient jamais les ICMP "fragmentation needed and DF was set" (très courant), les NAT qui ré-écrivent les options TCP et ignorent les ICMP... ca n'a aucune chance de fonctionner en pratique.

Il y a toujours la méthode RFC 4821, mais comme elle est désactivée par défaut sur tous les OS, c'est d'efficacité limitée.

Si tu veux garder ton architecture à base de tunnels VxLAN, je pense que faire du MSS clamping pour TCPv4 et laisser PMTUd se débrouiller en IPv6 doit le faire.

Heh, comment dire, IPv6 et Azure... hm, même AWS fait mieux de nos jours.

Par ex depuis 11, le RDNSS est ignoré, sauf si on est en v6 only...

Je sais pas vous, mais moi, j'y vois une invitation à faire du v6-only :-)