Peu probable mais merci de l’info, ça peut servir.

J’ai un peu avancé en creusant côté client et côté site.

En fait, le client s’est planté, ça marche quand on accède directement à:
https://www.bca.fr/reparateur-web/login.action 
<https://www.bca.fr/reparateur-web/login.action>

Ce qui ne marche pas, c’est quand on y arrive par:
https://www.bca.fr/ <https://www.bca.fr/>
(puis Votre Espace, puis Portail Réparateur)

Parce qu’en passant par là, on est envoyé sur:
http://reparateur.bca.fr/reparateur-web/login.action 
<http://reparateur.bca.fr/reparateur-web/login.action>
qui fait un 302 vers:
https://www.bca.fr/reparateur-web/login.action 
<https://www.bca.fr/reparateur-web/login.action>

Et ça semble être le 302 qui ne passe pas depuis les PC (tous à priori) du 
client.
Pareil avec Edge et Chrome.
reparateur.bca.fr et www.bca.fr <http://www.bca.fr/> arrivent sur la même IP, 
et il y a bien un certificat pour *.bca.fr <http://bca.fr/> sur les 2.

Une petite recherche sur F5 et HTTP 302 montrent que c’est un sujet à problème.

> Le 21 juin 2022 à 23:01, Pierre LANCASTRE <pierre.lancas...@gmail.com> a 
> écrit :
> 
> Hello
> 
> Peut être autre piste (j'ai eu le cas @home) : carte réseau du pc client 
> configure en Jumbo mtu. Le lb du serveur syn/ack en Jumbo. Et paf ça marche 
> plus. --> du coup chez moi je mss clamp a 1460 tout ce qui va vers le wan. Je 
> reste en Jumbo en local pour optimiser les transfers avec le NAS syno.
> 
> ++
> 
> Pierre
> 
> Le mar. 21 juin 2022 à 22:46, Alain Bitschiné via frnog <frnog@frnog.org 
> <mailto:frnog@frnog.org>> a écrit :
> Bonjour,
> 
> Qu’est-ce qui te fait penser à un problème de MTU ? Tu as de la fragmentation 
> côté client ?
> Côté serveur je ne vois pas de réduction de MTU. De chez moi le TCP MSS est à 
> 1460 sur les paquets SYN dans les deux sens, et je ne vois pas de perte sur 
> les gros paquets.
> 
> Une piste si tu as de la fragmentation côté client... il y a une chose à 
> savoir sur les F5 BigIP : ils n’aiment pas trop les paquets doublement 
> fragmentés. Ils n’acceptent pas les fragments trop petits (je n’ai plus la 
> limite en tête) si ce n’est pas le fragment final.
> J’ai déjà vu ça dans le cas d’un client qui envoyait des paquets fragmentés, 
> qui étaient ensuite à nouveau fragmentés à cause d’un tunnel GRE pour une 
> protection DDoS côté serveur. Le F5 bloquait le petit fragment intermédiaire… 
> et donc la session TCP. Ici ça a été résolu en ajustant le TCP MSS au niveau 
> des routeurs d’accès Internet côté serveur.
> Je doute que le F5 BigIP casse le PMTU Discovery. En revanche, un firewall 
> sur le chemin pourrait bloquer les paquets ICMP nécessaires...
> 
> Alain Bitschiné
> 
> > Le 21 juin 2022 à 20:36, David Ponzone <david.ponz...@gmail.com 
> > <mailto:david.ponz...@gmail.com>> a écrit :
> > 
> > J’ai un problème assez étrange, et je cherche des éléments de réponse.
> > 
> > Un client peut accéder à:
> > 
> > https://www.bca.fr <https://www.bca.fr/>
> > Mais pas à:
> > https://www.bca.fr/reparateur-web/login.action 
> > <https://www.bca.fr/reparateur-web/login.action> 
> > <https://www.bca.fr/reparateur-web/login.action 
> > <https://www.bca.fr/reparateur-web/login.action>>
> > 
> > Alors que la seconde URL est parfaitement joignable pour moi (donc même AS 
> > que mon client) ou depuis Bouygues FTTH ou depuis Orange Mobile.
> > Plus délicat: connecté en VPN SSL pour accéder au site depuis la même IP 
> > publique que mon client: ça marche.
> > 
> > Le client ne peut pas non plus accéder à la seconde URL depuis un site chez 
> > SFR.
> > 
> > Le site www.bca.fr <http://www.bca.fr/> <http://www.bca.fr/ 
> > <http://www.bca.fr/>> est chez OBS, et semble être derrière un BigIP (si 
> > j’en crois la réponse du serveur HTTP).
> > 
> > J’ai donc tendance à penser que c’est le BigIP qui va pas bien, ou alors 
> > une merdouille de MTU (d’ici à ce que le BigIP casse le PMTU Discovery, il 
> > n’y a qu’un pas).
> > 
> > Je cherche donc d’autres personnes qui auraient une impossibilité d’accès à 
> > la seconde URL.
> > Ca me permettrait de confirmer que ça vient pas de moi et SFR, et d’entamer 
> > les démarches pour établir un contact avec les gens qui gèrent le BigIP en 
> > question...
> > 
> > Merci
> > 
> > David Ponzone
> > 
> > 
> > ---------------------------
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/ <http://www.frnog.org/>
> 
> 
> ---------------------------
> Liste de diffusion du FRnOG
> http://www.frnog.org/ <http://www.frnog.org/>


---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à