Bonjour à tous,

C'est mon premier post, je ne suis pas sur que ce soit le bon sous-forum, désolé si me suis trompé.

Je viens chercher de l'aide pour un drole de problème avec ma Livebox 5.

(Contexte : je voudrais prendre un tunnel IP chez Milkywan mais avant je voudrais m'assurer que je peux établir un tunnel GRE à travers ma livebox.)

J'essaye de monter un tunnel GRE entre 2 machines virtuelles, l'une derrière ma livebox et l'autre en vps (Hetzner) avec une IP publique.
Les 2 VM sont sous debian 12 (image cloud), pas de règle de firewall et fraichement installées. Ça donne quelque chose comme ca :


                                 GRE   172.16.0.0/24
     ┌─────────────────────────────────────────────────────────────────────┐
   .1│                                                                     │.2
┌────▼──────┐                       ┌───────────┐                   ┌──────▼────┐
│           │    LAN                │           │                   │           │
│           │    192.168.1.0/24     │           │                   │           │
│    VM1    │◄─────────────────────►│ Livebox 5 │◄─────INTERNET────►│    VM2    │
│           │.29                  .1│           │                   │ (Hetzner) │
│           │                       │           │                   │           │
└───────────┘                       └───────────┘                   └───────────┘

J'ai fait les configurations suivantes :

Sur la livebox :

• Firewall en mode "Personalisé"
• Ajout régle personalisé pour autorisé le GRE "GRE any any accepter"
• Bail DHCP fixe pour la VMA
• NAT du protolaire du GRE vers VM1

Sur la VM1 :
ip tunnel add tun1 mode gre remote @IP_PUPLIQUE_VM2 local 192.168.1.29
ip link set tun1 up
ip addr add 172.16.0.1/24 dev tun1
ip link set mtu 800 tun1

Sur la VM2 :
ip tunnel add tun1 mode gre remote @IP_PUPLIQUE_LIVEBOX local @IP_PUPLIQUE_VM2
ip link set tun1 up
ip addr add 172.16.0.2/24 dev tun1
ip link set mtu 800 tun1

Le tunnel est up et j'arrive à ping les adresses respectives de l'autre bout du tunnel.

Les problèmes ont commencé quand j'ai essayé de tester le débit avec iperf3, je n'ai pas de connexion que ce soit avec le serveur sur VM1 ou sur VM2 et l'erreur suivante au bout d'un petit moment :
iperf3: error - unable to receive parameters from client:J'ai installé un serveur web (Caddy) sur la VM2 pour un test plus basique et je ne peux pas non plus récupérer l'index depuis VM1.

Après plusieurs heures d'investigations principalement à base de tcpdump, j'ai finis par remarquer que je recevais des paquets au niveau de VM1 (donc après la box et le NAT) avec l'adresse IP publique de la Livebox en destination.

18:23:55.779418 IP @IP_PUB_VM2  > 192.168.1.29: GREv0, length 64: IP 172.16.0.2.34878 > 172.16.0.1.5201: Flags [S], seq 887485962, win 65360, options [mss 760,sackOK,TS val 1337682372 ecr 0,nop,wscale 7], length 0
18:23:55.779451 IP 192.168.1.29 > @IP_PUB_VM2: GREv0, length 64: IP 172.16.0.1.5201 > 172.16.0.2.34878: Flags [S.], seq 168426657, ack 887485963, win 65076, options [mss 760,sackOK,TS val 1941687249 ecr 1337682372,nop,wscale 7], length 0
18:23:55.797153 IP @IP_PUB_VM2  > @IP_PUB_LB5: GREv0, length 56: IP 172.16.0.2.34878 > 172.16.0.1.5201: Flags [.], ack 1, win 511, options [nop,nop,TS val 1337682391 ecr 1941687249], length 0
18:23:55.797153 IP @IP_PUB_VM2  > @IP_PUB_LB5: GREv0, length 93: IP 172.16.0.2.34878 > 172.16.0.1.5201: Flags [P.], seq 1:38, ack 1, win 511, options [nop,nop,TS val 1337682391 ecr 1941687249], length 37
18:23:56.040691 IP @IP_PUB_VM2  > @IP_PUB_LB5: GREv0, length 93: IP 172.16.0.2.34878 > 172.16.0.1.5201: Flags [P.], seq 1:38, ack 1, win 511, options [nop,nop,TS val 1337682635 ecr 1941687249], length 37
18:23:56.793683 IP 192.168.1.29 > @IP_PUB_VM2: GREv0, length 64: IP 172.16.0.1.5201 > 172.16.0.2.34878: Flags [S.], seq 168426657, ack 887485963, win 65076, options [mss 760,sackOK,TS val 1941688264 ecr 1337682372,nop,wscale 7], length 0
18:23:56.811146 IP @IP_PUB_VM2  > @IP_PUB_LB5: GREv0, length 56: IP 172.16.0.2.34878 > 172.16.0.1.5201: Flags [.], ack 1, win 511, options [nop,nop,TS val 1337683405 ecr 1941687249], length 0
18:23:58.810208 IP 192.168.1.29 > @IP_PUB_VM2: GREv0, length 64: IP 172.16.0.1.5201 > 172.16.0.2.34878: Flags [S.], seq 168426657, ack 887485963, win 65076, options [mss 760,sackOK,TS val 1941690280 ecr 1337682372,nop,wscale 7], length 0
18:23:58.828192 IP @IP_PUB_VM2  > @IP_PUB_LB5: GREv0, length 56: IP 172.16.0.2.34878 > 172.16.0.1.5201: Flags [.], ack 1, win 511, options [nop,nop,TS val 1337685422 ecr 1941687249], length 0
Session iperf3 tcp port 5201, avec VM1 en serveur et VM2 en client/initiateur. Capture sur l'interface de VM1

Les deux premiers paquets (SYN & SYN/ACK) sont NATé correctement mais pas les suivants.
Le troisième paquet (ACK de fin d'initialisation de la session tcp) n'est pas NATé mais arrive quand meme jusqu'à la VM1, qui l'ignore car il ne lui est pas destiné.
A ce moment la, pour VM1 le paquet SYN/ACK (trame 2) n'a jamais été acquité, ce qui occasionne les retransmissions que on voit ensuite, notamment en trame 6.

Je ne comprends ni pourquoi ni comment je peux retrouver l'IP publique de ma livebox dans mon LAN. D'autant plus que au niveau 2, l'adresse MAC des trames non NATé est bien celle de VM1 (vérifié avec un switch en coupure en port-mirroring)

Ce que j'ai testé coté VM :

• 2 VM sur le même LAN avec des configurations similaires : le tunnels monte et iperf3 fonctionne ;
• Tests iperf3 en mode udp : ne fonctionne pas non plus (mais j'ai l'impression que meme en mode udp, iperf établis d'abord une sessions tcp) ;
• Tests avec goben (https://github.com/udhos/goben) en alternative à iperf3 : meme résultat en tcp, par contre le tests udp fonctionne ;
• Baisser la mtu des interfaces GRE : pas mieux ;
• Port mirroring (avec un petit switch) entre la livebox et le LAN : je ne vois rien de plus ou de moins que sur l'interface de VM1.

Ce que j'ai essayé coté livebox :

• Firewall en mode "Faible" (pass all) ;
• Supression et recréation des règles de NAT/Firewall ;
• Supression de la règle de firewall (NAT uniquement) : aucun paquet n'arrive sur le LAN (ce qui est logique mais je voulais verifier) ;
• et j'ai bien évidemment redémarré la box au moins 4 ou 5 fois.

J'avoue que j'arrive à court d'idée, est ce que quelqu'un à déjà vu quelque chose de similaire ? Est ce que j'ai fais une erreur bête quelque part ?

Qlem.

Peux-tu établir ton tunnel GRE sur IPv6 au lieu d'IPv4? Pour voir si c'est le NAT de la livebox qui cause le souci.

La Livebox est connue pour faire pas mal de choses étranges à tout ce qui n'est pas TCP ou UDP, malheureusement. Dès qu'on veut faire autre chose que du web, j'ai tendance à conseiller de la remplacer par un autre routeur.

ip link set mtu 800 tun1

C'est très petit... 1300 doit le faire, à minima.

Bon j'ai fait quelques tests supplémentaires en cette fin d’après midi.

J'arrive à établir un tunnel GRE entre les adresses IPv6 de VM1 et VM2, et je n'ai plus de problème, les tests ping et iperf3 TCP/UDP fonctionnent.
Ce qui me fait dire que c'est effectivement le NAT GRE de la Livebox 5 qui est en cause.

Par contre les performances via le tunnel GREv6 sont catastrophiques, à peine 1 à 10 Mbps sur les tests iperf3 (selon si le client est sur VM1 ou sur VM2).
Mais j'ai l'impression que les performances de la Livebox 5 en ipv6 sont mauvaises tout court, en dehors du tunnel (ipv6 publique à ipv6 publique) j'ai un ping 4 fois plus élevé et un débit 5 fois inférieur que en ipv4.

Entre VM1 et VM2 hors tunnel :
 - Ping v4 ~20ms ;
 - Ping v6 ~80ms ;
 - Débit v4 ~ 300Mbps (le max de mon offre) ;
 - Débit v6 ~60Mbps avec de fortes fluctuations.

En l’état le GREv6 ne me semble pas viable, à voir si je fais une croix sur le GRE en partant vers du L2TP ou si je remplace la LB5 (mais il faut alors que je trouve un ONT).

Mais j'ai l'impression que les performances de la Livebox 5 en ipv6 sont mauvaises tout court, en dehors du tunnel (ipv6 publique à ipv6 publique) j'ai un ping 4 fois plus élevé et un débit 5 fois inférieur que en ipv4.

Bonsoir,

Depuis un accès Sosh (FTTH à Paris en LB5) similaire au tien, je n'ai jamais vu de différences aussi importantes de débit/latence entre ip6 et ip4, y compris vers un VPS Hetzner.

Un client lambda derrière la LB présente aussi ces différences ?

Bonjour,

J'ai refait des tests ce matin et j'ai un débit ipv6 trés variable entre les 2 VMs, de moins de 10 Mbps à plus de 250 Mbps sur plusieurs tests consécutifs (résultats similaires sur la VM et sur un pc connecté directement derrière la Livebox)
J'ai aussi fait des tests de débit vers un serveur iperf3 publique sans constater aucun problème.

Cependant j'ai toujours un ping élevé en ipv6 entre mes 2 VMs (~120ms contre 20 en ipv4), alors que j'ai un ping tout a fait normal vers le DNS ipv6 Google.

Aucun changement du coté du tunnel GRE, j'ai toujours les mêmes problèmes de NAT en ipv4 et de débit à l’intérieur du GRE ipv6 qui reste autour de 2 Mbps.

J'ai un routeur sous OpenWRT qui traine dans un coin et je vais récupérer un ONT dans les prochains jours. Le comportement de ma LB5 me semble très aléatoire, particulièrement dès que j'ajoute des règles de NAT et/ou de firewall, je vais la remplacer, j'ai bon espoir que ce soit mieux.

Faire du GRE avec une IP dynamique d'un coté, c'est pas top, et encore plus si l'un des endpoints se trouve derrière un NAT. Le GRE n'est pas au dessus de TCP ou l'UDP, mais au même niveau, donc il faut un helper (qui est sûrement déjà présent) dans ton routeur qui fait du nat (ta livebox) pour pouvoir le router vers la bonne machine correctement. Bref, c'est du bricolage du même niveau que pour faire passer du ftp actif.
Si je le dis autrement, le GRE est parfait tant que tu ne fais que le router (niveau 3 du modèle OSI), public<=>public ou rfc1918<=>rfc1918. Quand tu commences à vouloir lui faire passer du NAT (niveau 4 du modèle OSI), tu peux considéré que c'est perdu. On peut s'en sortir avec le mode "DMZ", mais ca reste un bricolage infâme, pire que le nat helper.

A ce titre la, du bon vieux l2tp (sécurité cassé, mais pas pire que du GRE, et souvent accéléré en hardware), ou mieux, du wireguard (sécurité au top), tout deux basé sur UDP, sont bien plus adaptés à ton cas car géré correctement au niveau de la livebox.