Même en le redémarrant tu as pas de dialogue de niveau 3 ?, curieux ca semble être un appareil en panne si c'est le cas après reload...
C'est un appareil natté je suppose, tu as essayé de voir si les requêtes source était bien vu que ton éditeur quand cela marchait? Au pire place là derrière une box classique pour t'affranchir que le problème vient bel et bien de ton shield. Je rejoins l'analyse detaillée d'adrien... Le lun. 30 nov. 2020 à 17:25, Olivier Vailleau <olivier.vaill...@gmail.com> a écrit : > Bonjour tout le monde, > > Actuellement, l'objet IoT ne tente plus de sortir sur le net.. je ne sais > pas pourquoi. Je suis en train de revoir avec l'intégrateur pourquoi > l'objet est devenu muet. (il s'est peut-être résigné à son triste sort). > Je vais essayer d'obtenir ces traces et voir les pistes d'augmentation des > timeOut. > > Merci pour toutes vos réponses. > Olivier. > > > Le lun. 30 nov. 2020 à 16:53, Adrien Rivas <tera...@gmail.com> a écrit : > >> Bonjour Olivier, >> >> Il est possible que tu aies un timeout au niveau TCP. >> >> Si l'interruption intervient assez rapidement, tu peux suivre le dialogue >> en faisant au choix : >> >> diagnose debug flow filter saddr ip_iot (ou dia debug flow filter daddr >> ip_serveur si tu connais la destination) >> diagnose debug flow trace start 15000 >> diagnose debug enable >> >> Tu devrais obtenir à un moment donné un motif de déconnexion >> (probablement un TTL timeout), surtout si la machine ne fait pas de >> dialogue régulièrement. Si elle discute toutes les x minutes, édites la >> policy spécifique à ton équipement (con firewall policy, edit x) et >> modifies la TTL pour ne plus avoir de timeout. >> >> Le soucis peut aussi venir de l'interception SSL (règle sans utm dans ce >> cas), de la proxification, ou sur un 60E de l'asic offloading (si si), dans >> ce dernier cas un set npu-offload-disable et un set-auto-asic-offload >> disable devraient régler quelques soucis. >> >> Si tu est en version 6.2.x ou 6.4.x, dommage, en tant que bêta testeur tu >> n'as plus qu'à ouvrir un ticket chez Fortinet pour faire reconnaître et >> corriger ton bug. >> >> Le lun. 30 nov. 2020 à 16:45, sofiane JALID <sofiane.ja...@gmail.com> a >> écrit : >> >>> Bonjour >>> >>> >>> Verifie que tu n'est pas un réseau tcp au bout d'un certain délai >>> >>> >>> >>> Le lun. 30 nov. 2020 à 11:07, Olivier Vailleau < >>> olivier.vaill...@gmail.com> >>> a écrit : >>> >>> > Bonjour les collistiers, >>> > >>> > Je pose une petite question technique ici, pour laquelle je ne trouve >>> pas >>> > de réponse via mon ami google. >>> > >>> > Depuis peu, nous avons dans notre LAN un joli dispositif IoT, qui >>> souhaite >>> > causer vers son service cloud en websocket en gardant une connexion tcp >>> > ouverte en permanence. C'est mon premier équipement censé causer en >>> > websocket et garder la tcp ouverte >>> > La causerie ne marche pas et l'intégrateur me dit que c'est à cause de >>> mon >>> > firewall fortigate qui interrompt la connexion après quelques secondes. >>> > >>> > J'ai bien éliminé les autres pistes : les inspections de paquet sont >>> > désactivées, nos ip sont autorisées chez le cloud, et je trace bien >>> dans >>> > mes logs que la connexion n'est pas bloquée par mon firewall. >>> > >>> > Je n'arrive pas à savoir si le fortigate interrompt la liaison, ou >>> s'il est >>> > capable de la supporter. Je ne trouve pas de doc fortigate qui puisse >>> > m'aider sur le sujet. >>> > >>> > Quelqu'un dans la liste a-t-il dû faire face au même cas d'usage, à >>> savoir >>> > faire traverser du websocket à un fortigate ? >>> > Merci d'avance pour votre lecture et vos retour éventuels. >>> > >>> > Olivier >>> > >>> > --------------------------- >>> > Liste de diffusion du FRnOG >>> > http://www.frnog.org/ >>> > >>> >>> --------------------------- >>> Liste de diffusion du FRnOG >>> http://www.frnog.org/ >>> >> --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
