Pour information il semble qu'il est déjà documenté des problème L2TP chez Bouygues : https://lafibre.info/incidents-ftth/bridage-l2tp-chez-bouygues/24/

Ce que j'ai déjà essayé / testé
- Pour rappel la même configuration sur une SIM SFR 5G fonctionnait
- J'ai essayé de désactiver NPt et de faire du NAT66, mais même résultat
- Quelque chose d'étrange : si je me connecte via un VPN Wireguard sur mon pfSense, et que j'accède à internet via le tunnel L2TP sur la sim Bouygues/NRJ alors je n'ai plus les problèmes TCP...
- J'ai essayé une IPv6 manuelle plus courte que celle attribuée via SLAAC sur mon LAN car celle attribuée via mon VPN wireguard, mais le problème TCP persiste.

Est ce que je quelqu'un de Milkywan pourrrait me donner l'IPv6 du a1kx côté D2S sur Paris pour que j'essaye de monter le tunnel L2TP directement par IPv6 de mon backup, pour eliminer un problème de CGNAT coté Bouygues ?

Bonjour à tous,
J'écris car j'ai un problème avec un tunnel L2TP chez Milkywan qui est établi sur une connexion NRJMobile donc sur le réseau Bouygues Télécom.
J'utilise cette ligne 5G en backup avec un tunnel L2TP Milkywan.

Voici ma configuration :

• Une carte SIM 5G (maintenant NRJmobile) dans un routeur 5G "maison" sur OpenWrt. Ce dernier obtient une IPv4 CGNAT et une IPv6 avec une déléguation /64
• Ce routeur fait du NAT en IPv4 et fourni une IPv6 du préfix précédent sur sa patte LAN
• Sur cette patte LAN est connecté mon routeur principal pfSense
• Sur ce pfSense l'interface WAN2 (car backup) est donc reliée au routeur 5G et obtient une IPv4 (locale) et une IPv6 déléguée
• Sur ce pfSense j'ai configuré un tunnel L2TP via Milkywan sur l'interface WAN2. Le tunnel est bien monté
• Enfin j'utilise du NPt sur le pfsense pour changer les IPv6 de mes réseaux locaux (ayant une IPv6 correspondant au WAN1) avec le préfixe correspondant au tunnel L2TP

Pour information cette configuration fonctionnais correctement jusque là sur une connexion 5G SFR (que j'ai changée pour une NRJMobile). Donc lorsque mon WAN1 tombe, je bascule sur le backup sur le tunnel L2TP sur la ligne 5G, avec NPt faisant la correspodance pour ne pas changer mes IPv6 sur les LAN

Voici le problème :
Depuis que j'ai changé d'opérateur mobile, j'ai des problèmes à établir des connexions TCP à travers le tunnel L2TP.
Sur ce tunnel je suis bien capable de faire un ping vers les IP souhaitée mais impossible d'établir une connexion TCP
Par exemple ci joint une capture réseau sur l'interface L2TP du pfSense avec un ping IPv6 vers ip.lafibre.info qui abouti bien puis la connexion TCP qui ne fonctionne pas. A noter l'adresse IPv6 de mon côté qui correspond la la traduction via NPt.
Ci joint la même capture sur le client côté LAN. On voit que tous les packets passent bien le parefeux avec la bonne traduction NPt.

Avez vous une idée d'où pourrait venir le problème ?
Merci pour votre aide

salut,
désolé, j'ai pas lu toutes les pages juste les 8 premières mais je suis aussi confronté à ça sur notre infra.
Mon constat lié à ma petit expérience, sachant qu'on a choisi de mettre cloudflare devant les gros clients donc ca aide :
- la plupart des bots liés au search sont respectueux (google, bing, ...) et respecte le crawl-delay que tu peux ajouter dans un robots.txt donc bloquer bing ou google c'est pas toujours une bonne solution.
Garder en tête que plus un site répond vite et plus le bot augmente le rythme.

- les bots liés à anthropic n'ont aucun respect et moi je bloque le user agent qui se présente comme anthopic (les IP commencent par 216 en général, c'est chez aws je crois). On dépasse les 300.000 requêtes par jour de anthropic chez certains clients. et ca insiste pendant des jours même bloqué.
- filtrage par pays avec maxmind geoip pour filtrer le trafic qui n'a aucun sens sur un site franchophone.
- je filtre les user-agents chrome et firefox inférieur à 1xx (ca filtre les gamins qui scannent avec un vieux script tout pourri)
- je filtre quelques AS qui hébergent de la merde, on le sait, tout le monde le sait.

enfin, on test aussi CrowdSec et sa base d'IP malveillantes.

La dernière chose que j'ai mis en place en test c'est le honeypot. Une IP essaie de lire l'url .env ou .credentials ... t'es ajouté à la ban list.

J'ajoute que j'ai lu aussi que les vrais navigateurs chrome notamment, ont un mécanisme qui permet de les identifier parmi les faux user agent via une requête particulière.
Je l'ai pas exploité encore, mais je crois que Cloudflare Turnstile (le recaptcha cloudflare) utilise entre autre cela.

Il faut probablement privilégier l'IPv6, sauf s'ils limitent par /64 (ou pire /56).

Ils ne précisent pas pour la limitation en IPv6, mais la plupart des solutions IPv6 côté serveur ou CDN pour limiter ou banIP (un DNS que je ne liste pas banIP durant 900 secondes - soit 15 minutes - si on dépasse ce genre de limites), c'est en /64.

Concernant Bouygues qui détourne le trafic DNS, ce n'est pas le cas chez moi :

Si j'interroge google, sur un domaine IPv4 only (deezer.com), je n'ai pas de réponse à la requête AAAA. Par contre, avec ceux de bouygues, oui.

Tant mieux, mais curieux.
Il y a très peu d'APN différents, je pense qu'une configuration matérielle chez nous doit faire la différence (routeur 4G, smartpohne en partage de connexion, hotpsot 4G, etc).

Heu...
Vous êtes au courant que ce ne sont pas vraiment les députés qui écrivent les textes puisque pas assez compétents?

Donc la question est de savoir quels sont les lobbyistes qui les leurs ont écrits.