Auteur Sujet: Firewall IPv6 & délégation de préfixe dans la nouvelle màj Bbox 18.2.12 (Lu 65966 fois)

jurbain · « **Réponse #156 le:** 22 avril 2025 à 08:06:15 »

Hello,

Voici ce que j'ai pu trouvé en terme d'appel API:

En GET
api/v1/dhcp6/prefixdelegation
Avec une réponse du type
[ { "dhcp": { "prefixdelegation": [ { "id": 1, "enable": 1, "prefixend": "", "prefixstart": "2001:XXXX:XXXX:XXX", "securitylevel": "Normal", "macaddress": "", "type": 1 }, { "id": 2, "enable": 1, "prefixend": 3, "prefixstart": "2001:XXXX:XXXX:XXX", "securitylevel": "Low", "macaddress": "YY:YY:YY:YY:YY:YY", "type": 0 }, { "id": 3, "enable": 1, "prefixend": 1, "prefixstart": "2001:XXXX:XXXX:XXX", "securitylevel": "Normal", "macaddress": "YY:YY:YY:YY:YY:YY", "type": 0 } ] } } ]
type = 0, pour le statique, type = 1 pour le dynamique, si dynamique alors prefixend = "" si statique alors un des trois /64 posssible

En POST
api/v1/dhcp6/prefixdelegation?btoken=<the_token>
et dans le corp de la requête
enable=1&prefixstart=2001%3Axxxx%3Axxxx%3Axxx&prefixend=1&securitylevel=Normal&type=0&macaddress=yy%3Ayy%3Ayy%3Ayy%3Ayy%3Ayy
à remplir avec les XXXX et yy qui vont bien selon le schéma du GET précédent

En DELETE
api/v1/dhcp6/prefixdelegation/z
passer en Z l'id de l'entrée à supprimer

A priori et sauf dans le cas du POST (le token état passé en paramétre) il y a aussi le token qui est passé dans le headers de la requête sous Cookie. Comme j'ai testé tout cela en repiquant la session de mon navigateur et via les outils de développement intégré je ne sais pas l'ensemble minimum et nécessaire. Il faudrait tester cela avec du curl /postman / bruno, mais j'avoue que cela dépasse mon état de motivation :-)

Encore une API qui m'a semblé intéressante pour trouver les noms de devices connu de la BBOX c'est en:
GET
api/v1/hosts
ou en DELETE
api/v1/hosts/z
passer en Z l'id de l'entrée à supprimer

C'est avec cette dernière que j'ai émis le postulat que ce qui coince peut-être l'interface graphique c'est le manque de DUID pour les devices qui ne sont pas présenté dans la liste déroulante de l'interface graphique en destination pour la délégation de préfixe.

En espérant que cela puisse aider l'un ou l'autre.

kgersen · « **Réponse #157 le:** 22 avril 2025 à 12:07:29 »

merci des infos. pour utiliser l'api en mode ligne de commande et pour l'histoire du btoken c'est officiellement documenté. c'est jusqu'il n'y a pas "prefixdelegation" dans la doc.

la doc: https://developer.bouyguestelecom.fr/news/router-api-summary (pour démarrer et comprendre le cookie d'autentification)
l'api : https://api.bbox.fr/doc/apirouter/index.html (btoken expliqué au début).

quand tu fais un GET "api/v1/hosts', ton routeur n'y figure pas ? tu vois quoi pour un host qui apparait aussi dans la liste déroulante pour la délégation ?

jurbain · « **Réponse #158 le:** 22 avril 2025 à 12:39:19 »

le GET sur "api/v1/hosts" me renvoye un liste longue comme un jour sans fin de tous les devices s'étant connecté un jour ou pas à la bbox (j'ai depuis fait le ménage toujours via l'API d'ailleur). La documention non à jour que tu mentionnes n'indique pas la duid que j'ai dans le payload de retour dont voici un extrait ci-dessous pour ma gateway
{ "id": 43, "hostname": "UniFiCloudGatewayMaxB", "macaddress": "yy:yy:yy:yy:yy:yy", "duid": "", "ipaddress": "192.168.2.165", "type": "DHCP", "link": "Ethernet", "guest": 0, "devicetype": "Device", "firstseen": "2025-04-19T08:20:17+0200", "lastseen": 0, .... }

Donc pour résumé, je vois dans "api/v1/hosts" tous les devices récents (connecté) comme ancien (plus sur le réseau). J'y vois aussi ma gateway avec son adresse IPv6 wan. La seule chose qui semble différencier un device que je puisse sélectionner dans l'interface graphique pour la délégation de préfixe vs un autre que je ne vois pas dans l'interface graphique c'est vraiment ce champ duid. Ce champ duid est d'ailleurs assez bizzare car quand il est renseigné il a toujours la même forme:
"0X:00:00:00:00:01:00:01:2e:38:49:5d:60:3e:5f:44:a4:52"
avec X étant le seul discriminant d'un device à l'autre et une suite monotone croissante.

A moins de mettre la main sur un développeur de la box je pense que ce sera difficile de deviner ce qu'encode et signifie vraiment ce duid (la version de la doc en ligne ne mentionne pas ce champ).

Ceci dit comme il a a une méthode PUT sur le même endpoint je pourrais toujours essayer de forcer à la main un duid sur ma gateway et voir ce qui se passe. Mais vu que je suis arrivé à mes fin en via le prefixdelegation je ne vois pas trop l'intérêt pour moi. Peut-être d'autre auront envie de poursuivre cette voie.

kgersen · « **Réponse #159 le:** 22 avril 2025 à 13:47:01 »

Un DUID est envoyé par le host lors d'une requete DHCPv6. Si le DUID est a vide ca veut dire que la bbox n'a pas recu OU pas honoré une requete DHCPv6 venant de ce host.

Le plus souvent, le DUID est construit avec l'adresse MAC ou l'adresse MAC et une valeur temporelle (datetime).

Y'a t'il des IPv6 dans les résultats de "api/v1/hosts" ? (en général pas que pour ton UniFiCloudGatewayMaxB) .

Ce sujet étant ancien et souvent confus, je rappelle qu'en IPv6 pour que la bbox 'connaisse' un host et l'affiche dans la liste déroulante, il faut que cet host ai fait une demande d'adresse (pas de préfixe) en IPV6. Donc une requête DHCPv6 de type IA_NA (donc envoyer un DUID a la bbox)

En SLAAC ou manuel ca ne fonctionne pas (on parle du WAN la) car la bbox ne connait pas cette machine.

Résumé de configuration pour le routeur derriere la bbox:

coté WAN:
- interface wan : DHPCv6 (requete de type adresse pas préfixe).

a partir de la, on 'devrait' voir la machine dans la liste de délégation de préfixe sur la bbox -> lui déléguer un préfix, par exemple le xxx1.
Si ca ne marche pas, peut-etre que le DUID envoyé n'est pas accepter, vu qu'il est transformé en adresse MAC dans la liste déroulante, il faut que ce soit un DUID de type 1 ou 3 (type1=LLT=Link-layer address plus time ou type3=Link-layer address, cf doc Unify si c'est configurable)

Si on ne franchit pas cette étape, tenter avec l'api.

coté LAN:
- interface LAN: lettre en statique avec un adresse dans xxx1 (2001:xxxx:xxxx:xxx1::1/64 par par exemple)
- annoncer le préfixe 2001:xxxx:xxxx:xxx1 (en jargon on parle de "radvd" souvent).

L'autre méthode c'est: full dynamique pas je n'ai pas réussi a la faire fonctionner (a priori y'a un bug de routage coté bbox).

kgersen · « **Réponse #160 le:** 22 avril 2025 à 14:17:15 »

Citation de: jurbain le 22 avril 2025 à 12:39:19

"0X:00:00:00:00:01:00:01:2e:38:49:5d:60:3e:5f:44:a4:52"

En prenant X = 1 et en ajoutant un 0 devant, on dirait un type 1 (LLT):

Code: [Sélectionner]

python dec.py 00:01:00:01:2e:38:49:5d:60:3e:5f:44:a4:52

Input DUID Hex: 00:01:00:01:2e:38:49:5d:60:3e:5f:44:a4:52
Total DUID Length: 14 bytes
DUID Type: 1 [DUID-LLT - Link-layer address plus time]
Hardware Type: 1 [Ethernet]
Seconds since midnight (UTC), January 1, 2000: 775440733
Calculated Timestamp (UTC): 2024-07-28T00:12:13+00:00
Link-layer Address: 60:3e:5f:44:a4:52

Adresse mac (Link-layer Address) qui commence par 60:3e:5f -> Apple . C'est bien un appareil Apple qui a cette entrée ?

si tu as des entrée avec X=3 c'est du LL (type 3).

jurbain · « **Réponse #161 le:** 22 avril 2025 à 21:17:42 »

Merci pour cette explication DUID. Pour répondre aux questions il y a plusieurs chose à savoir:
* oui il s'agit bien d'un device Apple comme tu as pu le voire avec le code constructeur sur la MAC qui est bien dans la DUID
* s'agissant d'un portable il n'a plus de connecteur Ethernet et c'est donc via l'entremise d'un adaptateur USB ou Thunderbolt que je le connecter en cable pour mes tests.
* l'adresse MAC de la carte Wifi est bien celle que tu as pu voir dans le DUID rapporté (et que je n'avais pas reconnu comme tel, plus là dessus ci-dessous)

On se retrouve donc dans la situation ou une même machine Apple portable se connecte et apparait avec plusieurs MAC adresses différentes: une fois la docking station Thunderbolt 3, une fois l'adaptateur combiné Satech en USB et une troisième fois avec l'adaptateur UBS Belkin. Du coup la seule chose invariante en terme d'adresse MAC de cette machine Apple est la MAC adresse de sa carte Wifi. Et à priori Apple fait ce qui semble être la chose la plus logique elle construit le DUID de cette machine avec la seule chose invariante qu'elle ait, la MAC de la Wifi et ce quel que soit la méthode de connexion (adaptateur 1, 2 ou 3 ou via le wifi).

Ce qui du coup m'a mis dedans car dans le champ MAC adresse de l'endpoint ""api/v1/hosts" on trouve l'adresse MAC de l'adaptateur utilisé et non pas celui de la carte Wifi. J'en ai donc conclu de manière erronée que le DUID avait des champs constants alors qu'en réalité je voyais simplement toujours la même machine connectée via des adaptateurs différents.

Au final je constate donc que en terme de DUID pour la même machine mais via 3 adaptateurs différent j'ai:
* 01:00:00:00:00:01:00:01:2e:38:49:5d:60:3e:5f:44:a4:52
* 02:00:00:00:00:01:00:01:2e:38:49:5d:60:3e:5f:44:a4:52
* 03:00:00:00:00:01:00:01:2e:38:49:5d:60:3e:5f:44:a4:52

la partie finale du DUID étant la MAC adresse de la carte Wifi.

Du coup je ne suis pas sûr que le 01, 02 ou 03 soit vraiment le type. Cela me semble plutôt être le discriminant entre la même machine mais via un adaptateur différent.

Concernant les adresse IPv6, j'en ai effectivement pour chaque devices sur le style suivant:
"ip6address": [ { "ipaddress": "fe80::xxxx:xxxx:xxxx:xxxx", "status": "Preferred", "lastseen": "2025-04-21T22:35:14+0200", "lastscan": "2025-04-21T22:34:36+0200" }, { "ipaddress": "2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx", "status": "Preferred", "lastseen": "2025-04-21T22:35:56+0200", "lastscan": "2025-04-21T22:34:36+0200" }, { "ipaddress": "2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx", "status": "Preferred", "lastseen": "2025-04-21T22:35:11+0200", "lastscan": "2025-04-21T22:34:39+0200" } ]

Du coup entre tes explications et mes observations, je pense que pense que la gateway n'arrive pas à faire une demande d'adresse IPv6 correct (soit sans délégation de préfixe) sur son port WAN et du coup la bbox ne la reconnait pas. Ce qui est à priori dépassable par le passage par l'API (et à ce stade ça me va ainsi).

Je vais essayer de voir maintenant si j'arrive à configurer le côté LAN de ma gateway de la manière décrite par kgersen et ainsi obtenir un connectivité IPv6 derrière cette dernière. Plus d'information quand j'aurai pu procéder à ces essais.

kgersen · « **Réponse #162 le:** 23 avril 2025 à 11:11:00 »

Citation de: jurbain le 22 avril 2025 à 21:17:42

Au final je constate donc que en terme de DUID pour la même machine mais via 3 adaptateurs différent j'ai:
* 01:00:00:00:00:01:00:01:2e:38:49:5d:60:3e:5f:44:a4:52
* 02:00:00:00:00:01:00:01:2e:38:49:5d:60:3e:5f:44:a4:52
* 03:00:00:00:00:01:00:01:2e:38:49:5d:60:3e:5f:44:a4:52

la partie finale du DUID étant la MAC adresse de la carte Wifi.

Du coup je ne suis pas sûr que le 01, 02 ou 03 soit vraiment le type. Cela me semble plutôt être le discriminant entre la même machine mais via un adaptateur différent.

effectivement, j'ai mal regardé le nombre d'octets, il faut interpréter les infos comme suit:

Code: [Sélectionner]

* 01:00:00:00   00:01:00:01:2e:38:49:5d:60:3e:5f:44:a4:52
* 02:00:00:00   00:01:00:01:2e:38:49:5d:60:3e:5f:44:a4:52
* 03:00:00:00   00:01:00:01:2e:38:49:5d:60:3e:5f:44:a4:52

premiere partie un index sur 32 bits , et la deuxième le DUID, avec ici type 1 pour les 3.

jurbain · « **Réponse #163 le:** 25 avril 2025 à 09:37:31 »

Après plusieurs tests et plusieurs configurations différentes côté gateway toujours impossible d'avoir de l'IPv6 fonctionnel (tester via ping6) sur le réseau derrière la gateway. En effet même si je supprime dans la bbox la délégation de préfixe (que j'avais rentré à la main via l'API), que je configure le côté WAN de la gateway avec du DHCPv6 et un préfixe de /64 et fait la configuration qui va bien côté LAN, je me retrouve toujours avec le même préfixe 2001:XXXX:XXXX:XXX3. Donc que je fasse de la délégation de préfixe dans la bbox ou pas, côté gateway c'est du pareil au même. Ma conclusion est que sans DUID il semble possible de faire une entrée de routage statique sur la gateway mais ce n'est qu'une impression car la bbox n'a, au final, rien rentré dans sa table de routage pour faire revenir le trafic en réponse des requêtes des machines provenant du réseau derrière la gateway. Cela est concordant avec la résolution de ping6 free.fr sur l'adrresse IPv6 de free et l'absence de paquet en retour:
PING6(56=40+8+8 bytes) 2001:861:204b:b393:2554:6b9b:413b:d188 --> 2a01:e0c:1::1 ^C --- free.fr ping6 statistics --- 5 packets transmitted, 0 packets received, 100.0% packet loss

Fort de ce constat il ne me reste plus que deux options: soit la gateway Unifi ne transmet pas de DUID, soit celui qui est transmis par la gateway n'est pas reconnu par la bbox. Dans tous les cas la négociation en DHCPv6 semble fonctionner correctement et je vois dans les log de odcvp6c les traces suivantes:
Apr 25 08:10:43 HostName ubios-udapi-server[1079]: dhcp-client: (Re)starting odhcp6c (stateful) on eth4 Apr 25 08:10:43 HostName ubios-udapi-server[1590303]: odhcp6c[1590303]: (re)starting transaction on eth4 Apr 25 08:10:43 HostName odhcp6c[1590303]: (re)starting transaction on eth4 Apr 25 08:10:43 HostName ubios-udapi-server[1590303]: odhcp6c[1590303]: Starting SOLICIT transaction (timeout 4294967295s, max rc 0) Apr 25 08:10:43 HostName odhcp6c[1590303]: Starting SOLICIT transaction (timeout 4294967295s, max rc 0) Apr 25 08:10:44 HostName ubios-udapi-server[1590303]: odhcp6c[1590303]: Got a valid ADVERTISE after 1086ms Apr 25 08:10:44 HostName ubios-udapi-server[1590303]: odhcp6c[1590303]: IA_NA 0001 T1 0 T2 0 Apr 25 08:10:44 HostName ubios-udapi-server[1590303]: odhcp6c[1590303]: 2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx preferred 54000 valid 86400 Apr 25 08:10:44 HostName ubios-udapi-server[1590303]: odhcp6c[1590303]: IA_PD 0001 T1 0 T2 0 Apr 25 08:10:44 HostName ubios-udapi-server[1590303]: odhcp6c[1590303]: 2001:xxxx:xxxx:xxxx::/64 preferred 54000 valid 86400 Apr 25 08:10:44 HostName odhcp6c[1590303]: Got a valid ADVERTISE after 1086ms Apr 25 08:10:44 HostName odhcp6c[1590303]: IA_NA 0001 T1 0 T2 0 Apr 25 08:10:44 HostName odhcp6c[1590303]: 2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx preferred 54000 valid 86400 Apr 25 08:10:44 HostName odhcp6c[1590303]: IA_PD 0001 T1 0 T2 0 Apr 25 08:10:44 HostName odhcp6c[1590303]: 2001:xxxx:xxxx:xxxx::/64 preferred 54000 valid 86400 Apr 25 08:10:45 HostName ubios-udapi-server[1590303]: odhcp6c[1590303]: Starting REQUEST transaction (timeout 4294967295s, max rc 10) Apr 25 08:10:45 HostName ubios-udapi-server[1590303]: odhcp6c[1590303]: Send REQUEST message (elapsed 0ms, rc 0) Apr 25 08:10:45 HostName odhcp6c[1590303]: Starting REQUEST transaction (timeout 4294967295s, max rc 10) Apr 25 08:10:45 HostName odhcp6c[1590303]: Send REQUEST message (elapsed 0ms, rc 0) Apr 25 08:10:45 HostName ubios-udapi-server[1590303]: odhcp6c[1590303]: Got a valid REPLY after 2ms Apr 25 08:10:45 HostName odhcp6c[1590303]: Got a valid REPLY after 2ms Apr 25 08:10:45 HostName ubios-udapi-server[1590303]: odhcp6c[1590303]: IA_NA 0001 T1 0 T2 0 Apr 25 08:10:45 HostName ubios-udapi-server[1590303]: odhcp6c[1590303]: 2001:xxxx:xxxx:xxx0:xxxx:xxxx:xxxx:xxxx preferred 41799 valid 74199 Apr 25 08:10:45 HostName ubios-udapi-server[1590303]: odhcp6c[1590303]: IA_PD 0001 T1 0 T2 0 Apr 25 08:10:45 HostName ubios-udapi-server[1590303]: odhcp6c[1590303]: 2001:xxxx:xxxx:xxx3::/64 preferred 41799 valid 74199 Apr 25 08:10:45 HostName ubios-udapi-server[1590303]: odhcp6c[1590303]: T1 20899s, T2 33439s, T3 74199s Apr 25 08:10:45 HostName odhcp6c[1590303]: IA_NA 0001 T1 0 T2 0 Apr 25 08:10:45 HostName ubios-udapi-server[1590303]: odhcp6c[1590303]: entering stateful-mode on eth4 Apr 25 08:10:45 HostName ubios-udapi-server[1590303]: odhcp6c[1590303]: Starting <POLL> transaction (timeout 20899s, max rc 0) Apr 25 08:10:45 HostName odhcp6c[1590303]: 2001:xxxx:xxxx:xxxx:xxx3:xxxx:xxxx:xxxx preferred 41799 valid 74199 Apr 25 08:10:45 HostName odhcp6c[1590303]: IA_PD 0001 T1 0 T2 0 Apr 25 08:10:45 HostName odhcp6c[1590303]: 2001:xxxx:xxxx:xxx3::/64 preferred 41799 valid 74199 Apr 25 08:10:45 HostName odhcp6c[1590303]: T1 20899s, T2 33439s, T3 74199s Apr 25 08:10:45 HostName odhcp6c[1590303]: entering stateful-mode on eth4 Apr 25 08:10:45 HostName odhcp6c[1590303]: Starting <POLL> transaction (timeout 20899s, max rc 0)

Pour moi on voit donc bien le IA_NA avec une réponse dans le range 2001:XXXX:XXXX:XXX0 sur la patte WAN et ensuite via IA_PD la délégation de préfixe sur 2001:xxxx:xxxx:xxx3::/64.

Donc les prochaines étapes:
* trouver le DUID générer la gateway
* s'assurer que ce DUID est bien envoyé à destination de la bbox

kgersen · « **Réponse #164 le:** 25 avril 2025 à 12:58:02 »

si ton routeur demande un IA_PD c'est qu'il fait du dynamique... il reçoit bien xxxx:3 qu'il configure ensuite sur son LAN. Le IA_NA est optionnel dans ce cas.

pour la configuration dynamique:
si ca ne marche depuis ton LAN: soit les ping sont bloqués (firewall quelque part) soit la bbox ne route pas correctement les paquets de retour (bug bbox éventuellement repéré déjà par d'autres gens du forum mais on n'a pas de certitude car chez certains ca fonctionne (cf remii notamment)).

-> désactive tout firewall pour tester (dans la bbox et dans ton routeur), ne teste pas que des pings mais plutot https://test-ipv6.com/ depuis un PC avec navigateur ou en ligne de commande sur ton routeur ou un PC :

Code: [Sélectionner]

curl api6.ipify.org(ca doit afficher ton IPv6) (sur Windows c'est curl.exe pas "curl" tout court).

pour la config statique:

as tu moyen de faire une capture sur le port WAN ? si oui tu verra le DUID envoyé.

en configuration statique, on ne devrait voir que IA_NA pas de IA_PD.
Ta config WAN ipv6 doit être DHCPv6 (pour IA_NA) et "single network" (pas de demande de délégation).
dans la bbox ajouter un entrée delegation statique vers ton routeur (manuellement si ca marche sinon avec l'api?). choisir xxxx:1 par exemple
Ta config LAN ipv6 doit être "static", mettre le prefix xxxx:1 et surtout cocher IPv6 RA pour le distribuer sur le LAN.

si tu peux poster des captures des pages de configuration de tes interface pour WAN et LAN ca aiderai aussi. je n'ai pas de Cloud Gateway sous la main.

pour resumer: soit tu essais de faire marcher la configuration dynamique , soit la statique mais pas les 2 meme temps...

jurbain · « **Réponse #165 le:** 25 avril 2025 à 15:56:05 »

Voici donc la configuration de la gateway Unifi pour le WAN en mode DHCPv6 (dynamique donc) avec la bbox en mode délégation de préfixe (une seule entrée, dynamique et préfixe auto, sécurité faible, rien dans la délégation statique). Pare-feu laissé sur normal et sa règle pour le port 25 et 445 (cf copie d'écran)

Dans cette configuration et en direct (ligne de commande sur la gateway), voici la négociation DHCPv6 (Solicit, Advertise, Request et Reply) via tcpdump:
12:34:32.963420 IP6 (flowlabel 0xeb848, hlim 1, next-header UDP (17) payload length: 154) fe80::eea:14ff:fecd:848b.546 > ff02::1:2.547: [bad udp cksum 0xa574 -> 0x5eee!] dhcp6 solicit (xid=161c88 (elapsed-time 0) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67 opt_82) (client-ID hwaddr type 1 zzzzzzzz848b) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0))) 12:34:32.964829 IP6 (class 0xc0, flowlabel 0x1877f, hlim 64, next-header UDP (17) payload length: 162) fe80::56c4:5bff:feb1:11ac.547 > fe80::eea:14ff:fecd:848b.546: [udp sum ok] dhcp6 advertise (xid=161c88 (IA_NA IAID:1 T1:0 T2:0 (IA_ADDR 2001:xxxx:xxxx:xxxx0:a81f:6cac:11b7:f046 pltime:54000 vltime:86400)) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix 2001:xxxx:xxxx:xxx3::/64 pltime:54000 vltime:86400)) (client-ID hwaddr type 1 zzzzzzzz848b) (server-ID hwaddr type 1 zzzzzzzz11ac) (reconfigure-accept) (DNS-server 2001:xxxx:xxxx:xxx0:56c4:5bff:feb1:11ac) (DNS-search-list lan.)) 12:34:34.414816 IP6 (flowlabel 0xeb848, hlim 1, next-header UDP (17) payload length: 194) fe80::eea:14ff:fecd:848b.546 > ff02::1:2.547: [bad udp cksum 0xa59c -> 0x5cb1!] dhcp6 request (xid=4638ca (elapsed-time 0) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 zzzzzzzz848b) (server-ID hwaddr type 1 zzzzzzzz11ac) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0 (IA_ADDR 2001:xxxx:xxxx:xxx0:a81f:6cac:11b7:f046 pltime:54000 vltime:86400)) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix 2001:xxxx:xxxx:xxx3::/64 pltime:54000 vltime:86400))) 12:34:34.417307 IP6 (class 0xc0, flowlabel 0x1877f, hlim 64, next-header UDP (17) payload length: 162) fe80::56c4:5bff:feb1:11ac.547 > fe80::eea:14ff:fecd:848b.546: [udp sum ok] dhcp6 reply (xid=4638ca (IA_NA IAID:1 T1:0 T2:0 (IA_ADDR 2001:xxxx:xxxx:xxx0:a81f:6cac:11b7:f046 pltime:54000 vltime:86400)) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix 2001:xxxx:xxxx:xxx3::/64 pltime:54000 vltime:86400)) (client-ID hwaddr type 1 zzzzzzzz848b) (server-ID hwaddr type 1 zzzzzzzz11ac) (reconfigure-accept) (DNS-server 2001:xxxx:xxxx:xxx0:56c4:5bff:feb1:11ac) (DNS-search-list lan.))

Dans cette configuration et en direct (ligne de commande sur la gateway), j'obtiens ceci:
root@UniFiCloudGatewayMaxBruguier:/data/udapi-config# ping6 free.fr PING free.fr(www.free.fr (2a01:e0c:1::1)) 56 data bytes 64 bytes from www.free.fr (2a01:e0c:1::1): icmp_seq=1 ttl=55 time=12.5 ms 64 bytes from www.free.fr (2a01:e0c:1::1): icmp_seq=2 ttl=55 time=12.1 ms 64 bytes from www.free.fr (2a01:e0c:1::1): icmp_seq=3 ttl=55 time=12.7 ms 64 bytes from www.free.fr (2a01:e0c:1::1): icmp_seq=4 ttl=55 time=12.8 ms 64 bytes from www.free.fr (2a01:e0c:1::1): icmp_seq=5 ttl=55 time=12.6 ms 64 bytes from www.free.fr (2a01:e0c:1::1): icmp_seq=6 ttl=55 time=12.6 ms 64 bytes from www.free.fr (2a01:e0c:1::1): icmp_seq=7 ttl=55 time=12.3 ms 64 bytes from www.free.fr (2a01:e0c:1::1): icmp_seq=8 ttl=55 time=12.8 ms ^C --- free.fr ping statistics --- 8 packets transmitted, 8 received, 0% packet loss, time 7010ms rtt min/avg/max/mdev = 12.095/12.541/12.767/0.218 ms root@UniFiCloudGatewayMaxBruguier:/data/udapi-config# curl api6.ipify.org 2001:xxxx:xxxx:xxxx0:a81f:6cac:11b7:f046

Donc une connectivité IPv6 complète (même en laissant les règles de pare-feu telle que présentée) pour la gateway.

Maintenant côté LAN c'est autre chose. La configuration est telle que présentée dans le copie d'écran (soit délégation de préfixe et le reste en automatique). On voit d'ailleurs bien la que le préfixe qui va être utilisé pour le côté LAN est le 2001:xxxx:xxxx:xxx3::/64 qui correspond au IA_PD-prefix. Pas de firewall configurer sur la gateway.

Dans cette configuration, si je prend une machine du réseau LAN et que je refais mes tests tel quel je les avaient effectué sur la gateway c'est le néant:
user@Machine ~ % ping6 free.fr PING6(56=40+8+8 bytes) 2001:xxxx:xxxx:xxx3:bc4e:fb03:88ae:ef57 --> 2a01:e0c:1::1 ^C --- free.fr ping6 statistics --- 6 packets transmitted, 0 packets received, 100.0% packet loss user@Machine ~ % curl api6.ipify.org curl: (28) Failed to connect to api6.ipify.org port 80 after 75012 ms: Couldn't connect to server

Donc dans cette configuration plus de connectivité IPv6. Idem sur le site https://test-ipv6.com/. Idem d'ailleurs si je change la configuration d'automatique (SLAAC) à DHCPv6.

kgersen · « **Réponse #166 le:** 25 avril 2025 à 16:51:38 »

si tu fais un tcpdump (coté wan) pendant un ping ou un curl (depuis le lan) vois-tu passer le trafic vers la bbox et pas revenir ?

Le but est de savoir ou ca "coince" (a ton routeur ou au delà). Tu peux aussi si tu as une machine extérieur tenter des ping ou curl entrant vers une IPv6 du LAN (xxx3) et voir en capture sur wan si tu vois passer ou pas le paquet (mais faut ouvrir dans la bbox "parefeu faible" je crois ou créer une regle)

En mode dynamique, je ne mettrai pas DHCPv6 coté WAN, juste SLAAC c'est la config que remii utilise et qui marche ( y'a peut-etre un bug dans la bbox si la meme machine fait une demande IA_NA et IA_PD en meme temps ?).
Apres je ne sais pas si ton routeur supporte SLAAC+prefix delegation en temps meme coté WAN.. ton interface est différente des captures d'écran qu'on trouve sur le Net ou sur ce forum.
par exemple: https://lafibre.info/ubiquiti/probleme-avec-lipv6-de-free-via-la-cloud-gateway-fibre-dubiquiti/msg1109514/#msg1109514

t'es bien a jour niveau OS de ton routeur ?

jurbain · « **Réponse #167 le:** 25 avril 2025 à 23:23:45 »

Concernant ma version de la gateway je suis super à jour. J'étais en 9.0.114 qui date de janvier de cette année (les versions et antérieures avaient sans doute une interface graphique différente). La seule chose qui diffère avec le post que tu mentionnes est le thème graphique sombre.

La je suis en train de passer 9.1.120 sortie ce jour et pour lequel il est indiqué: "Improved the IPv6 Server validation and improved the WAN IPv6 settings user experience."

Selon tes conseils j'ai passé sur la config suivante côté WAN: SLAAC, Prefix delegation 64 (cf copie d'écran) et suis resté en auto sur la partie LAN (idem à la copie d'écran du poste précédent)

Voici la trace d'un ping6 free.fr depuis une machine du LAN derrière la gateway et pris via un tcpdump sur l'interface WAN de la gateway:
23:07:03.604340 IP6 (flowlabel 0x40e00, hlim 63, next-header ICMPv6 (58) payload length: 16) 2001:xxxx:xxxx:xxx3:c16:f0ae:c45a:e238 > 2a01:e0c:1::1: [icmp6 sum ok] ICMP6, echo request, id 32959, seq 0 23:07:04.609686 IP6 (flowlabel 0x40e00, hlim 63, next-header ICMPv6 (58) payload length: 16) 2001:xxxx:xxxx:xxx3:c16:f0ae:c45a:e238 > 2a01:e0c:1::1: [icmp6 sum ok] ICMP6, echo request, id 32959, seq 1 23:07:05.612709 IP6 (flowlabel 0x40e00, hlim 63, next-header ICMPv6 (58) payload length: 16) 2001:xxxx:xxxx:xxx3:c16:f0ae:c45a:e238 > 2a01:e0c:1::1: [icmp6 sum ok] ICMP6, echo request, id 32959, seq 2 23:07:06.614913 IP6 (flowlabel 0x40e00, hlim 63, next-header ICMPv6 (58) payload length: 16) 2001:xxxx:xxxx:xxx3:c16:f0ae:c45a:e238 > 2a01:e0c:1::1: [icmp6 sum ok] ICMP6, echo request, id 32959, seq 3 23:07:07.618144 IP6 (flowlabel 0x40e00, hlim 63, next-header ICMPv6 (58) payload length: 16) 2001:xxxx:xxxx:xxx3:c16:f0ae:c45a:e238 > 2a01:e0c:1::1: [icmp6 sum ok] ICMP6, echo request, id 32959, seq 4 23:07:08.618460 IP6 (flowlabel 0x40e00, hlim 63, next-header ICMPv6 (58) payload length: 16) 2001:xxxx:xxxx:xxx3:c16:f0ae:c45a:e238 > 2a01:e0c:1::1: [icmp6 sum ok] ICMP6, echo request, id 32959, seq 5 23:07:09.619501 IP6 (flowlabel 0x40e00, hlim 63, next-header ICMPv6 (58) payload length: 16) 2001:xxxx:xxxx:xxx3:c16:f0ae:c45a:e238 > 2a01:e0c:1::1: [icmp6 sum ok] ICMP6, echo request, id 32959, seq 6 23:07:10.623262 IP6 (flowlabel 0x40e00, hlim 63, next-header ICMPv6 (58) payload length: 16) 2001:xxxx:xxxx:xxx3:c16:f0ae:c45a:e238 > 2a01:e0c:1::1: [icmp6 sum ok] ICMP6, echo request, id 32959, seq 7 23:07:11.625252 IP6 (flowlabel 0x40e00, hlim 63, next-header ICMPv6 (58) payload length: 16) 2001:xxxx:xxxx:xxx3:c16:f0ae:c45a:e238 > 2a01:e0c:1::1: [icmp6 sum ok] ICMP6, echo request, id 32959, seq 8 23:07:12.626642 IP6 (flowlabel 0x40e00, hlim 63, next-header ICMPv6 (58) payload length: 16) 2001:xxxx:xxxx:xxx3:c16:f0ae:c45a:e238 > 2a01:e0c:1::1: [icmp6 sum ok] ICMP6, echo request, id 32959, seq 9
Pas l'ombre d'un "echo reply" comme je peux le voire quand je ping depuis la gateway en ligne de commande en directe.