Bonjour à tous,

J'ai un tunnel GRE avec endpoints ipv6 chez un fournisseur bien connu du forum. Depuis plusieurs semaines, le tunnel est indisponible de manière régulière et sur des périodes assez longues (~1 semaine). A ce jour, je n'ai pu faire aucun rapprochement avec des évènements sur mon installation.
Le tunnel GRE est normalement sur un serveur. Lorsque cela ne fonctionne pas, je teste également sur le routeur (wrt) derrière l'ONT ou directement avec un PC derrière l'ONT. Sans succès à chaque fois. Lorsque le tunnel remonte, c'est sans changement de ma part.

Information importante, je vois des paquets arriver avec tcpdump (ping par https://dnschecker.org/all-tools.php par exemple), ce qui veut dire que le tunnel fonctionne au moins dans un sens. Les paquets réponses sont visibles aussi, mais quelque chose bloque quelque part au retour.

Je me dis que j'ai forcément manqué quelque chose.

Voici un test de ce matin car le tunnel est en rade, test intercos et ipv4 avec PC derrière l'ONT.

interface enp0s25 connecté à l'ONT SFR :

rc-service net.enp0s25 restart
net.enp0s25               | * Bringing down interface enp0s25
net.enp0s25               | *   Stopping dhcpcd on enp0s25 ...sending signal TERM to pid 18573
net.enp0s25               |waiting for pid 18573 to exit
net.enp0s25               | [ ok ]
net.enp0s25               | * Bringing up interface enp0s25
net.enp0s25               | *   dhcp ... *     Running dhcpcd ...dhcpcd-10.1.0 starting
net.enp0s25               |DUID 00:01:00:01:2e:84:97:e7:a4:4e:31:33:6a:e8
net.enp0s25               |enp0s25: waiting for carrier
net.enp0s25               |enp0s25: carrier acquired
net.enp0s25               |enp0s25: IAID 0e:bd:72:66
net.enp0s25               |enp0s25: IA type 25 IAID 00:00:00:01
net.enp0s25               |enp0s25: adding address fe80::9f4a:4acb:c676:9fea
net.enp0s25               |enp0s25: adding address 2a02:8428:aaaa:bbb1::47/64
net.enp0s25               |enp0s25: adding route to 2a02:8428:aaaa:bbb1::/64
net.enp0s25               |enp0s25: rebinding lease of 88.137.105.XX
net.enp0s25               |enp0s25: probing address 88.137.105.XX/24
net.enp0s25               |enp0s25: rebinding prior DHCPv6 lease
net.enp0s25               |enp0s25: soliciting an IPv6 router
net.enp0s25               |enp0s25: Router Advertisement from fe80::5555
net.enp0s25               |enp0s25: adding default route via fe80::5555
net.enp0s25               |lo: adding reject route to 2a02:8428:aaaa:bbb0::/56
net.enp0s25               |enp0s25: REPLY6 received from fe80::5555
net.enp0s25               |enp0s25: renew in 300, rebind in 480, expire in 600 seconds
net.enp0s25               |enp0s25: delegated prefix 2a02:8428:aaaa:bbb0::/56
net.enp0s25               |enp0s25: leased 88.137.105.XX for 600 seconds
net.enp0s25               |enp0s25: adding route to 88.137.105.0/24
net.enp0s25               |enp0s25: adding default route via 88.137.105.1
net.enp0s25               | [ ok ]
net.enp0s25               | *     received address 88.137.105.XX/24
net.enp0s25               | [ ok ]

Test réseau SFR OK :

ping 1.1.1.1 -I enp0s25
PING 1.1.1.1 (1.1.1.1) de 88.137.105.XX enp0s25 : 56(84) octets de données.
64 octets de 1.1.1.1 : icmp_seq=1 ttl=251 temps=6.53 ms

Test endpoint GRE6 OK :

ping 2a0b:aaa:b::29
PING 2a0b:aaa:b::29 (2a0b:aaa:b::29) 56 octets de données
64 octets de 2a0b:aaa:b::29 : icmp_seq=1 ttl=57 temps=8.21 ms

Flush des tables du firewall :

nft flush ruleset

Autorisation du forward :

sysctl -w net.ipv4.ip_forward=1

Setup du tunnel gre1 et intercos :

ip -6 tunnel add gre1 mode ip6gre local 2a02:8428:aaaa:bbb1::47 remote 2a0b:aaa:b::29
ip -6 link set gre1 up
ip addr add 45.13.XXX.XX/32 dev gre1
ip route add default dev gre1
ip addr add 10.1.1.74/30 dev gre1
ip -6 addr add aaaa:bbbb:1::4a/126 dev gre1

Tests intercos FAIL :

ip route get 10.1.1.73
10.1.1.73 dev gre1 src 10.1.1.74 uid 1000

ping 10.1.1.73
PING 10.1.1.73 (10.1.1.73) 56(84) octets de données.
^C
--- statistiques ping 10.1.1.73 ---
1 paquets transmis, 0 reçus, 100 % paquets perdus, temps 0 ms

ping 10.1.1.73 -I gre1
PING 10.1.1.73 (10.1.1.73) de 10.1.1.74 gre1 : 56(84) octets de données.
^C
--- statistiques ping 10.1.1.73 ---
2 paquets transmis, 0 reçus, 100 % paquets perdus, temps 1025 ms

ip route get aaaa:bbbb:1::49
aaaa:bbbb:1::49 from :: dev gre1 proto kernel src aaaa:bbbb:1::4a metric 256 pref medium
 
ping aaaa:bbbb:1::49
PING aaaa:bbbb:1::49 (aaaa:bbbb:1::49) 56 octets de données
^C
--- statistiques ping aaaa:bbbb:1::49 ---
2 paquets transmis, 0 reçus, 100 % paquets perdus, temps 1007 ms

Tests réseau gre1 FAIL :

ip route get 1.1.1.1
1.1.1.1 dev gre1 src 45.13.XXX.XX uid 1000
    cache expires 198sec mtu 1448
 
ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) octets de données.
^C
--- statistiques ping 1.1.1.1 ---
2 paquets transmis, 0 reçus, 100 % paquets perdus, temps 1003 ms

ping 1.1.1.1 -I gre1
PING 1.1.1.1 (1.1.1.1) de 45.13.XXX.XX gre1 : 56(84) octets de données.
^C
--- statistiques ping 1.1.1.1 ---
2 paquets transmis, 0 reçus, 100 % paquets perdus, temps 1010 ms

il faudrait voir ce que donnent des mtr 1.0.0.1 [-I gre1]

un traceroute ne donne rien, mais cela semble logique car l'interco ne répond pas.

Le problème date de la mise en place ou est-il apparu plus tard ?

La mise en place s'est faite sans soucis. Le problème est apparu plusieurs mois plus tard. Et c'est intermittent depuis.

Vu le début de l'IPv6, il s'agit sans doute de Milkywan.

Mais vu l'intermittence de la chose et le fait que ça refonctionne sans rien faire, je vote pour un truc que SFR a fait sur son réseau, routeur mal configuré ou autre.Y avait des problèmes avec d'autres proto du style, comme L2TP où le débit est bridé (c'était chez orange je crois). Donc c'est pas impossible qu'un truc similaire se produise avec SFR.

T'aurais la possibilité de tester depuis une autre connexion au moment où ça ne marche pas ? Le doute serait assez vite levé.

Mais vu l'intermittence de la chose et le fait que ça refonctionne sans rien faire, je vote pour un truc que SFR a fait sur son réseau, routeur mal configuré ou autre.Y avait des problèmes avec d'autres proto du style, comme L2TP où le débit est bridé (c'était chez orange je crois). Donc c'est pas impossible qu'un truc similaire se produise avec SFR.

Je pense aussi à ça mais autant j'avais du débit bridé autant il n'y a pas grand monde avec une coupure complète. Après les tunnels IP6-IP6 ne sont pas la norme non plus.

T'aurais la possibilité de tester depuis une autre connexion au moment où ça ne marche pas ? Le doute serait assez vite levé.

Non, car l'IP endpoint de mon côté est fixe, donc forcément lié à ma connexion fibre.

Information importante, je vois des paquets arriver avec tcpdump (ping par https://dnschecker.org/all-tools.php par exemple), ce qui veut dire que le tunnel fonctionne au moins dans un sens. Les paquets réponses sont visibles aussi, mais quelque chose bloque quelque part au retour.

J'avais pas percuté tout de suite, mais serait-on en présence de routage asymétrique ? Dans un sens ça fonctionne mais pas dans l'autre et parfois, le routeur change et ça tombe sur un qui ne bloque pas le trafic (ou emprunte le même qu'à l'aller) ?

Je pense a une bidouille de paquets chez SFR, clairement.

Merci pour la confirmation.

Après la solution serait de prendre une ftth chez nous, ipv6 marche nativement

J'attends l'offre XP FIBRE qui n'arrivera pas  .

Un tunnel IP4 au lieu d'IP6 pourrait changer quelque chose point de vue magouille SFR ?