Il y a encore une bourde (mais c'est bizarre qu'il reçoive quand même une ip dans ce cas...)

Tu as mis auto à la place de dhcp pour la ligne iface enxb827eb71a4fc inet6 (à moins que tu l'aies corrigé après ?)
 
Est-ce que tu arrives à ping ta freebox ou autre équipement via leur ip ? C'est peut-être un problème de DNS simplement. Que contient /etc/resolv.conf ? Normalement il doit y avoir l'ip de la freebox soit :

nameserver 192.168.1.254

Ce n'est pas un oubli, en mettant dhcp, ça tourne sans fin, sans obtenir de réponse de ma freebox.
Donc j'ai mis auto à la place ayant lu ceci : "Autrement, IPv6 peut être configuré automatiquement en utilisant l'autoconfiguration sans état (stateless address autoconfiguration ou SLAAC) qui est spécifiée en utilisant auto à la place de dhcp dans la section inet6 :"

Ah oui c'est vrai, vu que je n'utilise que très rarement la config auto/dhcp sur serveur, je m'en rappelais plus. auto est pour le SLAAC et dhcp pour dhcpv6.

Tous les équipements en 192.168.1.x ne répondent pas, j'obtiens défaillance générale. Ce qui est étonnant car je m'attendrai à avoir hôte inexistant ou délais dépassé.

Essaies dans un premier temps de virer tout ce qui concerne wireguard (en commentant, pas besoin de l'effacer), car il se peut que les règles interfèrent. Tu as aussi viré ton script de pare-feu ? Car c'est un coup à tout bloquer si les règles ne sont pas bonnes.

EDIT : défaillance générale, c'est sur windows ça. Que donne un ping à partir du rasp ? C'est surtout ça qui m'intéresse.

Exemples à tester :
ping 192.168.1.254
ping 2a01:6e00:10:410::2
ping4 lafibre.info
ping6 lafibre.info

Content de voir que ça fonctionne 

Pour windows qui n'accède pas au réseau local, si les paramètres sont identiques au client andoid c'est assez étonnant... Faudrait que je fasse le test de mon côté.

Test effectué  : La navigation sur un partage SMB ainsi que le net fonctionne en même temps. Et je n'ai rien d'autre que la règle de NAT, comme toi. C'est peut-être comme je l'avais mentionné avant, wg-quick qui merde. Chez moi je suis en configuration tout manuel :

Merci renaud07 pour ton retour.
La solution était pourtant évidente, mais je ne l'ai vue que ce soir,... j'ai changé l'adresse DNS de Free en 212.xxx.xxx.xxx par celle de la freebox 192.168.1.254 et tout fonctionne aussi en local

Merci beaucoup pour tout le temps que tu m'as consacré !!!

En fait non, j'ai confondu mon problème d'accès au net qui fonctionne depuis un moment, avec mon problème d'accès à mon réseau classique en 192.168.1.x qui ne fonctionne pas.

J'essaye aussi de paramétrer ipv6 dans wireguard mais sans grand résultat pour le moment.
ip.lafibre.info me ressort :
Connectivité IP :    Attention : Vous n’avez pas de connectivité IPv6 native.
Connectivité IPv4 (via requête DNS) OK : IPv4 publique = www.xxx.yyy.zzz
Connectivité IPv4 (via IPv4 littérale) OK : IPv4 publique = www.xxx.yyy.zzz
Connectivité IPv6 (via requête DNS) hors-service
La version du protocole IP utilisée par défaut est IPv4
Informations IP :
Reverse DNS IPv4 est fmx92-1-www-xxx-yyy-zzz.fbx.proxad.net
Reverse DNS IPv6 est (Vous n'avez pas de connectivité IPv6)
IP locales : 192.168.2.1, 2a01:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
Informations TCP :
Port TCP source utilisé par votre connexion IPv4 : TCP 56748 et TCP 56749 (via IPv4 littérale) (Plus d'informations)
Port TCP source utilisé par votre connexion IPv6 : (Vous n'avez pas de connectivité IPv6)
Port TCP destination utilisé : TCP 80

sur une interface wireguard, AllowedIPs fonctionne :
 - en sortie de l'interface: comme un routage (routage local a l'interface wg, il faut aussi qu'une route correspondante soit installée dans l'OS).
 - en entrée de l'interface: comme un filtre sur adresse source (ACL)

donc en général:
- coté serveur il ne faut mettre qu'une IP (ou range éventuellement) , celle du client.
- coté client il faut mettre 0.0.0.0/0 si on veut que tout son traffic passe par le vpn de façon a ce qu'il laisse entrée n'importe quelle IP source (ie les retour).

Ce qui peut se passer c'est que certaines surcouches (comme wg-quick) établissent en plus les routes dans l'OS en fonction de la valeur de AllowedIPs. Si ce n'est pas fait, par exemple, indiqué sur le client, que 0.0.0.0/0 doit sortir par wg0 alors meme si il y a 0.0.0.0/0 en AllowedIPs ca ne sortira pas par la bien qu'autorisé a entrer par la.

extrait de la doc de wg-quick :

It infers all routes from the list of peers’ allowed IPs, and automatically adds them to the system routing table. If one of those routes is the default route (0.0.0.0/0 or ::/0), then it uses ip-rule( to handle overriding of the default gateway.

Pas mal de gens ne réalisent pas ceci quand il utilise la commande 'wg' directement: ca ne change pas les routes dans l'OS. Alors que wg-quick change les routes dans l'OS. donc bien faire attention quand on utilise les 2 commandes directement (je recommande de n'utiliser que wg-quick).

Ce qui peut se passer c'est que certaines surcouches (comme wg-quick) établissent en plus les routes dans l'OS en fonction de la valeur de AllowedIPs. Si ce n'est pas fait, par exemple, indiqué sur le client, que 0.0.0.0/0 doit sortir par wg0 alors meme si il y a 0.0.0.0/0 en AllowedIPs ca ne sortira pas par la bien qu'autorisé a entrer par la.

extrait de la doc de wg-quick :

Pas mal de gens ne réalisent pas ceci quand il utilise la commande 'wg' directement: ca ne change pas les routes dans l'OS. Alors que wg-quick change les routes dans l'OS. donc bien faire attention quand on utilise les 2 commandes directement (je recommande de n'utiliser que wg-quick).

Salut kgersen,

Je viens de vérifier et sauf erreur de ma part, j'utilise la commande wg-quick car j'ai suivi la procédure suivante :
pi @ raspberrypi: ~ $ mkdir wgkeys
pi @ raspberrypi: ~ $ cd wgkeys   
pi @ raspberrypi: ~ / wgkeys $ wg genkey > server_private.key   
Attention: écriture dans le fichier accessible au monde entier.
Envisagez de définir l'umask sur 077 et réessayez.

pi @ raspberrypi: ~ / wgkeys $ wg pubkey > server_public.key < serveur_private.key
pi @ raspberrypi: ~ / wgkeys $ wg genkey > client1_private.key   
Attention: écriture dans le fichier accessible au monde entier.
Envisagez de définir l'umask sur 077 et réessayez.
pi @ raspberrypi: ~ / wgkeys $ wg pubkey > client1_public.key < client1_private.key
pi @ raspberrypi: ~ / wgkeys $ ls
client1_private.key client1_public.key serveur_private.key serveur_public.key

pi @ raspberrypi: ~ / wgkeys $ sudo nano /etc/wireguard/wg0.conf     
[Interface]
Adresse = 192.168.2.254/24
PrivateKey = <server_private.key>
ListenPort = 51820

# remplacez eth0 par l'interface ouverte à Internet (par exemple, wlan0 si wifi)
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o enxb827eb71a4fc -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o enxb827eb71a4fc -j M$
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o enxb827eb71a4fc -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o enxb827eb71a4fc -j$

[Peer]
# Client1
PublicKey = <client1_public.key>
AllowedIPs = 192.168.2.1/32,
Endpoint = 192.168.1.1:51820

pi @ raspberrypi: ~ / wgkeys $ sudo wg-quick up wg0

pi @ raspberrypi: ~ / wgkeys $ sudo wg show


Comment et où dois-je vérifier que les routes ont été créées pour permettre aux clients d'accéder au réseau local en 192.168.1.x ?