Jean-Charles, J'ai trouvé hier la même cause et les mêmes raisons que tu indiques sur le thread suivant :
https://community.sophos.com/utm-firewall/f/vpn-site-to-site-and-remote-access/84759/t-mobile-nat64-and-openvpn Je te confirme que c'est bel et bien l'origine du soucis. Par contre j'ai du mal à comprendre ce qui pose soucis à OpenVPN dés lors qu'il obtient un literal IPv6. Un soucis de route ? J'ai appliqué les directives push-remove route-ipv6 et push-remove ifconfig-ipv6 et ça fonctionne sans soucis. Jérôme ________________________________ De : JCLB <j...@jclb.net> Envoyé : mercredi 30 décembre 2020 11:37 À : Jérôme Quintard <jquint...@outlook.com> Cc : frnog-t...@frnog.org <frnog-t...@frnog.org> Objet : RE: [FRnOG] [TECH] OpenVPN / Orange et 4G Bonjour, Les opérateurs mobiles font la même chose que sur le fixe. Ils déploient IPv6 et cherchent à retirer rapidement IPv4 du réseau interne afin de ne pas tourner en dual stack partout. La technique retenue est logiquement celle du DNS64+NAT64, elle est implémentée par Google et Apple depuis plusieurs années dans les OS mobiles. Lorsqu'une application joint un serveur IPv4 only, le DNS de l'opérateur crée à la volée un enregistrement AAAA sous la forme d'un WKP (well known prefixe IPv6 64:ff9b::/96 + l'IPv4 en hexadécimal). L'opérateur peut aussi utiliser un Network Specific Prefixe mais il faut alors un moyen de le configurer sur les clients, une RFC rend cela possible via PCP (le remplaçant de PMP qui fournit uPnP) et c'est donc plutôt destiné aux boxs domestiques. Par exemple si ton serveur est en IP 1.1.1.1, le DNS va retourner un AAAA 64:ff9b::101:101 Un équipement de NAT64 stateful va ensuite mapper ton paquet avec l'IPv4 correspondante et un port aléatoire. Chez Orange cette fonctionnalité est portée par des châssis SLB F5. Enfin, lorsque la connexion du smartphone est partagée en wifi, IPv4 est supporté via du XLAT464. Le téléphone traite donc la partie cliente de la double translation (CLAT) pour passer de v4 à v6, puis le NAT64 chez l'opérateur le retour à v4 sur internet. Android fournit également XLAT464 aux applications qui utiliseraient une adresse IPv4 en littéral, sans requête DNS donc. De son côté, Apple étant maitre plus en profondeur des middlewares utilisés, il gère de son côté la transformation d'une adresse IPv4 saisie en littéral en une IPv6 avec le préfixe WKP. C'est pour cette raison qu'Apple force depuis 2016 les app à supporter IPv6 au sens code. Les fonctions utilisées doivent permettre d'ouvrir un socket en v6 comme en v4. J'exposais ça ici https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flafibre.info%2Fipv6%2Fipv6-iphonex%2Fmsg689495%2F%23msg689495&data=04%7C01%7C%7C9dbf4e972e4845d0cb0f08d8acaef201%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637449214686761908%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8QCoOXMW%2Bd%2BbD7saF5jF23tENFG75c4CaqLOBDHawVY%3D&reserved=0 Cette RFC d'aide au déploiement peut aider à la compréhension https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8683.html&data=04%7C01%7C%7C9dbf4e972e4845d0cb0f08d8acaef201%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637449214686761908%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8Qdwjj1tN2yodTac2FOcdQTG6uuHqQYbEsJUkn4cOIo%3D&reserved=0 Le revers est que cette technique force à utiliser le DNS opérateur, à ma connaissance il n'est pas encore possible de spécifier soi-même un serveur DNS et traiter le DNS64 avec une configuration côté smartphone. Si vous souhaitez tester l'implémentation sur votre terminal, vous pouvez ouvrir une page web TLS avec l'adresse littérale et voir ce qui se passe. Ouvrez https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2F1.1.1.1%2F&data=04%7C01%7C%7C9dbf4e972e4845d0cb0f08d8acaef201%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637449214686761908%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Q6lNgDd%2ByyG4uOs97kMr2%2Bg8WqoDTkafWG11Xoj%2BOhI%3D&reserved=0 , aucun soucis Ouvrez https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2F%5B64%3Aff9b%3A%3A101%3A101%5D%2F&data=04%7C01%7C%7C9dbf4e972e4845d0cb0f08d8acaef201%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637449214686761908%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CpBbt%2BeFyWYXC3jHu6mP5o7AGC1rZKMPZMzAPotXxl0%3D&reserved=0 vous recevrez une erreur de certificat, sauf sous Safari avec IOS13 où les librairies Apple truandent la conversion jusqu'au contrôle du certificat, et modifient à la volée les adresses pour assurer la compatibilité avec NAT64. Sous IOS14 ça semble avoir disparu. Une en-tête IPv6 étant plus longue, et IPv6 ne fragmentant que sur les extrémités, il en résulte qu'un NAT64 mal configuré produira des paquets IPv6 trop gros... Tu indiques que ça marche en partage de connexion, et donc en XLAT464, peux-tu vérifier que pour un paquet émis au MTU max sur le laptop, le serveur reçoit 1 ou 2 paquets avec fragmentation ? En dehors de ça NAT64 ne pose problème que quand l'application effectue un contrôle de l'adresse littérale. Tu peux créer une conf OpenVPN "WKP" où tu spécifies l'IPv6 WKP générée avec l'IPv4 de ton serveur au lieu de son FQDN, ça permet généralement de démonter ou non ce genre de comportement de validation littérale. Jean-Charles BISECCO -----Message d'origine----- De : frnog-requ...@frnog.org <frnog-requ...@frnog.org> De la part de Jérôme Quintard Envoyé : mercredi 30 décembre 2020 01:39 À : Jérôme Quintard <jquint...@outlook.com> Cc : frnog-t...@frnog.org Objet : RE: [FRnOG] [TECH] OpenVPN / Orange et 4G Bon... on a avancé dans la compréhension du soucis et il n'est pas lié à la configuration d'OpenVPN. Pour faire simple : Android + 4G orange -> le client OpenVPN obtient pour adresse publique du serveur une IPv4 Android + 4G SFR -> IPv4 Apple + 4G SFR -> IPv4 Apple + 4G Orange -> IPv6 Pourquoi une IPv6 aucune explication d'autant qu'elle inexistante sur le net... Que ce soit OpenVPN, la VM, l'EIP associée c'est IPv4 uniquement... Côté client forcé la conf en IPv4 n'a aucun effet. Orange ne trouve, pour le moment, aucune origine ce lien avec les terminaux Apple. Dans tous les cas, aucun rapport avec notre conf. Une idée de votre côté ? Ou une modification de la conf du client pour "contourner" ? Jérôme ________________________________ De : frnog-requ...@frnog.org <frnog-requ...@frnog.org> de la part de Jérôme Quintard <jquint...@outlook.com> Envoyé : mardi 22 décembre 2020 14:44 À : Baptiste Chappe <baptiste.cha...@gmail.com>; Benoît Grangé <benoit.gra...@gmail.com> Cc : frnog-t...@frnog.org <frnog-t...@frnog.org> Objet : RE: [FRnOG] [TECH] OpenVPN / Orange et 4G Bah non MTU changé rien y fait. Une autre idée ?? ________________________________ De : Baptiste Chappe <baptiste.cha...@gmail.com> Envoyé : lundi 21 décembre 2020 15:05 À : Benoît Grangé <benoit.gra...@gmail.com> Cc : Jérôme Quintard <jquint...@outlook.com>; frnog-t...@frnog.org <frnog-t...@frnog.org> Objet : Re: [FRnOG] [TECH] OpenVPN / Orange et 4G Hello, Je pense aussi à un sujet de MTU Je ne compte plus les réseaux "présta/marketing" et les services de TPE bancaire sensible à la MTU (à base de openvpn pour sécuriser le fllux """"CB""""). Consigne => Passez votre OpenVPN à 1450/1430. Baptiste, Baptiste, Le lun. 21 déc. 2020 à 14:09, Benoît Grangé <benoit.gra...@gmail.com<mailto:benoit.gra...@gmail.com>> a écrit : Ça me fait penser à un problème de MTU ou Path MTU discovery qui finit par tomber en marche ^h ^h ^h panne dans certains cas. Le lun. 21 déc. 2020 à 12:22, Jérôme Quintard <jquint...@outlook.com<mailto:jquint...@outlook.com>> a écrit : > Salut à tous, > > Je sèche sur l'origine d'un soucis transitoire... > > Nos sites sont équipés d'un VPN MPLS d'Orange (BVPN) sur lequel nous > nous connectons depuis l'extérieur via OpenVPN. Le serveur OpenVPN est > installé sur leur solution flexible engine qui fait un bridge entre > l'extérieur et nos réseaux via une VM. > > Lorsque l'on se connecte, sur une machine, via le client OpenVPN que > ce soit en ethernet ou en WIFI l'ensemble fonctionne correctement. > > En 4G, si l'on a pas un RSSI très haut, impossible, avec le profil > client, depuis un mobile ou une tablette, que ce soit un iphone ou un > android, de se connecter à certains services (que ce soit du web, un flux > RTP, du CIFS). > > Les requêtes partent vers les différents services que l'on test (ex. > web), mais les réponses associées sont quasi inexistantes. On arrive > par exemple à avoir une page 404, mais dès que la réponse est trop > conséquente, aucune donnée n'arrive. Comme si de la QoS réduisait le > débit... alors qu'il y'en a pas. > > Par contre si l'on connecte une machine en partage de connexion avec > un mobile en 4G. La machine, n'a aucun soucis pour se connecter via > son client OpenVPN. > > Quelqu'un aurait des idées ? > > Jérôme > > --------------------------- > Liste de diffusion du FRnOG > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. > frnog.org%2F&data=04%7C01%7C%7C54869b4fd85b4319fe3408d8a67fef05%7C > 84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637442415685237654%7CUnknow > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC > JXVCI6Mn0%3D%7C1000&sdata=Jpna7a6tBK%2F5LYdlJ2Kld6hYIZ9R2wzOT60%2B > qapuCr4%3D&reserved=0<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Femea01.safelinks.protection.outlook%2F&data=04%7C01%7C%7C9dbf4e972e4845d0cb0f08d8acaef201%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637449214686761908%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FAkBBMuMPoluHTOeerVgMsBBXOWUsKadFq5M5TfZGIs%3D&reserved=0. > com/?url=http%3A%2F%2Fwww.frnog.org%2F&data=04%7C01%7C%7C54869b4fd > 85b4319fe3408d8a67fef05%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6 > 37442415685237654%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi > V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Jpna7a6tBK%2F5 > LYdlJ2Kld6hYIZ9R2wzOT60%2BqapuCr4%3D&reserved=0> > -- *Benoît Grangé* Mobile: 06 58 58 05 59 --------------------------- Liste de diffusion du FRnOG https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2F&data=04%7C01%7C%7C9dbf4e972e4845d0cb0f08d8acaef201%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637449214686761908%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=D0cI%2BXWH%2BkAgwBdyK9WDl9EAmXXhofcteDtitzmJmmo%3D&reserved=0<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2F&data=04%7C01%7C%7C9dbf4e972e4845d0cb0f08d8acaef201%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637449214686761908%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=D0cI%2BXWH%2BkAgwBdyK9WDl9EAmXXhofcteDtitzmJmmo%3D&reserved=0> --------------------------- Liste de diffusion du FRnOG https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2F&data=04%7C01%7C%7C9dbf4e972e4845d0cb0f08d8acaef201%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637449214686761908%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=D0cI%2BXWH%2BkAgwBdyK9WDl9EAmXXhofcteDtitzmJmmo%3D&reserved=0 --------------------------- Liste de diffusion du FRnOG https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2F&data=04%7C01%7C%7C9dbf4e972e4845d0cb0f08d8acaef201%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637449214686761908%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=D0cI%2BXWH%2BkAgwBdyK9WDl9EAmXXhofcteDtitzmJmmo%3D&reserved=0 --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
