Modem routeur Linksys WAG54GX2 et SPI

Utilisateur de Lns depuis des années déjà, je consulte assez irrégulièrement
ce forum, mais j'y trouve toujours des conseils très avisés. Merci en
particulier à Fréderic, et bien sur à "Maître" Climenole

Mon problème du jour est le suivant (j'ai passé une journée entière à chercher la réponse dans ce forum ... rien) :

Question principale :
Lorsque je boote mon PC, le Stateful Packet Inspection (SPI) de LNS
intercepte une bordée d'échanges entre le PC et mon disque réseau
monté en partage.


Je ne sais comment dire à LNS que mon disque est un copain animé
des meilleures intentions. J'ai essayé, sans effet, d'exclure les adresses IP
locales (192.168.1.xxx) dans les "options avancées :
.

Je précise que cela n'a aucune influence sur la fonctionnalité du disque, qui
est tout aussi accessible et performant avec que sans le SPI.
Je me satisferais donc parfaitement d'une solution qui éliminerait l'alerte ...
Mais comment faire puisqu'au contraire des deux filtrages ordinaires,
il semble n'y avoir aucun moyen "légal" de contrôler de façon fine le SPI.

Question subsidiaire : Mes communications Internet se font au travers d'un
Modem routeur Linksys WAG54GX2, sur lequel existe un filtrage SPI. Je l'ai
activé. Dans ces conditions, puis-je me permettre, sans risque, de désactiver
le SPI de LNS. Si oui, cela rendrait inutile la réponse à la question principale ...
qui deviendrait donc subsidiaire

Merci d'avance

Jacques

 

Bonjour,

Il semble que votre PC et votre disque réseau établissent des connexions avant que Look 'n' Stop ne soit lancé, ce qui provoque le problème.
Si vous êtes sous XP, essayez de démarrer Look 'n' Stop en mode service pour qu'il soit démarré plus tôt.
Sous Vista la seule solution actuelle serait de bloquer tout le trafic avant de lancer Look 'n' Stop, mais c'est peut être un peu brutal.

Sinon, au niveau de l'alerte, il n'est pas possible de filtrer les alertes du TCP SPF. Tout paquet autorisé par le jeu de règles passe ensuite automatiquement dans le TCP SPF et génère une alerte s'il n'appartient pas à une connexion existante (et si le paquet n'est pas une ouverture de connexion).
Une solution serait de bloquer les échanges avec une règle particulière qui indiquerait le port source (vu du PC) et le port dest, en supposant que ce port source est toujours 1027 (ou toujours entre 1024 et 1027 ou un peu plus, mais pas 1050 par exemple). Et pour cette règle vous supprimez l'alerte. Ainsi les paquets seront bloqués avant d'être transmis au TCP SPF.

Le champ qui permet d'exclure des adresses IP dans les options avancées, ne sert qu'à l'identification de la bonne interface réseau quand le choix est sur automatique, mais en aucun cas à indiquer des adresses IP acceptées sur le réseau.

Oui, si vous avez déjà un TCP SPF/SPI dans le modem, celui de Look 'n' Stop n'est pas indispensable. Ca vous permet quand même de détecter certaines anomalies au départ du PC.

Cordialement,

Frédéric

 

Je suis sous XP-SP3. J'avais essayé le "mode service", mais LNS n'a pas démarré du tout (en tout cas, pas d'icône en barre de tâche). J'ai même eu
toutes les peines du monde à repasser en mode "système". Il a fallu que je passe en mode "Menu démarrer", puis reboot, puis mode "système".

Mais, en procédant de la sorte, je bloquerai aussi des paquets qui, eux, font
partie de connexions existantes, car c'est précisément au SPI de faire la différence. Me trompe-je ??

Donc, en attendant une hypothétique version future, qui offrirait un tout petit peu de contrôle utilisateur sur le filtrage SPI, je supprimerai le SPI de lns, car le prix des beep-beep est trop élevé.

Merci à vous pour votre réponse rapide, et très cordialement,

Jacques

 

C'est curieux, il n'y a pas de problème en cours de ce type avec le mode de démarrage service.
Egalement curieux que le retour au mode système n'ait pas marché directement.

Les connexions sont bloquées juste le temps que Look 'n' Stop démarre (c'est l'objet de cette fonctionnalité).
Donc la fonctionnalité suppose que durant cette phase il n'y a normalement pas de connexion existante importante et que toute connexion peut attendre le lancement de Look 'n' Stop.

Je ne sais pas encore. Il y a plusieurs possibilités.

Il s'agit bien que de beep au démarrage, sur une 20aine de paquets ? ou est-ce que cela persiste sur par exemple une 100aine de paquets et sur une durée plus grande ? (et dans ce cas il y a un autre problème, ou tout n'a pas été compris)

Cordialement,

Frédéric

 

Je trouve également cela curieux. Etes vous bien certain que je sois le seul ? ou bien, étant donné que ce n'est pas, en soi, critique, peut-être que ce n'est pas signalé ?

Je ne suis pas certain de comprendre ce que vous désignez exactement par "la fonctionnalité"

Il ne s'agit "que" d'une vingtaine de "beep". En fait, en regardant de près, mon message initial, on voit onze paquets "orphelins" dans le sens de la sortie, assez rapprochés sur 70 secondes, puis un silence de 3'30, puis une salve de sept paquets en sens inverse en 14 secondes. Après, c'est fini ...

Je ne sais absolument pas interprêter cette chose étrange ...

Cordialement,

Jacques

 

Bonjour,

Je pense que ce serait quand même signalé, car c'est assez embêtant si Look 'n' Stop ne se lance plus après avoir changé cette option.

Je faisais référence à la fonctionnalité avancée qui permet de tout bloquer tant que Look 'n' Stop n'est pas lancé (via une clef de la base des registres, c'est décrit dans le post de l'annonce de la 2.06p2).
Vous disiez que ça va bloquer les paquets des connexions existantes, le but de la fonction est justement de ne pas avoir de connexion avant que Look 'n' Stop soit lancé.

Ok, c'est donc juste le temps qu'une connexion en cours soit abandonnée après quelques dernières tentatives.

L'explication est simplement qu'une connexion est établie avant que la fonction TCP SPF ne soit active. Et dès quelle est active (au lancement de Look 'n' Stop), les paquets semblent n'appartenir à aucune connexion connue (vu du TCP SPF) et sont donc bloquer. Quelques tentatives de reconnexions sont faites de part et d'autres, mais elles sont bloquées aussi.

Cordialement,

Frédéric