Dépendance d'instances

Bonjour,

j'utilise LnS 2.06p2 sous XP pro avec deux cartes réseau. Je lance donc deux fois LnS.

Première interface (instance associée en mode service), métrique plus courte, toutes les connexions (sauf FTP) : 192.168.0.2
Deuxième interface (instance associée en lancement par Base de Registre), métrique plus longue, trafic FTP : 192.168.0.1

Problème : si un deuxième PC (192.168.0.3) tente un ping sur 192.168.0.1, il faut que l'instance de 192.168.0.2 autorise les paquets pour qu'il y ait réponse au ping. Cette première instance est certes la seule à gérer le filtrage logiciel, mais il est étonnant qu'elle s'occupe des paquets ne concernant pas son interface... [en revanche, l'instance associée à 192.168.0.1 semble ne s'occuper que de son interface, sans interférer sur 192.168.0.2]

Autre chose : si je configure la première instance pour laisser passer les pings (ce qui devrait donc être indépendant), même si la deuxième instance a toutes les règles pour le ping, il n'y a pas d'echo tant que je n'ai pas "initié" les échanges en désactivant un instant le filtrage internet de la deuxième instance (réceptrice des pings). Autre symptôme similaire : si cette deuxième instance n'a pas les règles de ping mais juste une règle bloquante avec signalisation journal, alors les signalisations n'ont lieu qu'après cette même "initialisation des échanges". Bref, dans ces deux cas, tant qu'on n'a pas débloqué temporairement le filtrage internet, les paquets sont bloqués silencieusement, quelles que soient les règles.

En espérant avoir été clair...

Renard A.D.

PS : autre petite chose sans rapport : sur la première instance j'ai créé la règle "tout icmp" en dupliquant la règle "tout le reste" (je n'ai changé que le nom de la règle et le protocole). Lorsque dans le journal je demande à "Montrer la règle" d'une ligne "tout icmp", je suis dirigé vers la règle "tout le reste". En revanche, "ouvrir la règle" fonctionne.

 

Bonjour,

Est-ce que ces tests sont faits avec une instance démarrée en mode service et l'autre manuellement + choix de l'interface manuel ?

Si oui, est-il possible de confirmer ces tests sans lancer la 1ère instance en mode manuel, mais les 2 en mode normal ?

En fait en investiguant l'autre thread, je pense que la 2ème instance lancée ne marche pas correctement quand une première instance est lancée en mode service. De mon coté en mode non service c'est Ok (ping bien bloqué sur la bonne instance) et en mode service la 2ème instance ne bloque rien (et le ping n'est bloqué par aucune des instances).

Je ne suis pas sûr d'avoir bien compris la partie où vous parler "initiation de la connexion", mais ça me fait penser qu'il peut y avoir d'autres paquets ICMP nécessaires à gestion du réseau qui sont initialement bloqué, et empêchent un comportement normal.
J'ai noté par exemple des paquets ICMP (qui ne sont pas des pings) lors de ces tests.

Cordialement,

Frédéric

 

Bonjour,

les tests étaient effectivement effectués avec une instance "service" et une instance "manuelle". Cependant, j'ai fermé ces deux instances et relancé les deux en "manuel" et les symptômes persistent.

A propos de "l'initiation de connexion" : lorsque 192.168.0.3 tente un ping sur 192.168.0.1, et que 192.168.0.2 a été configurée pour les laisser passer, alors ce sont les règles de 192.168.0.1 qui devraient s'appliquer (blocage ou réponse au ping... au choix). Pourtant, l'instance de 192.168.0.1 ne réagit pas, c'est à dire qu'elle ne signale ni les réponses autorisées (lorsque la règle en question est valide), ni les paquets bloqués (dans le cas contraire). Et en pratique, il n'y a pas de réponse au ping. Conclusion, l'instance associée à 192.168.0.1 ne semble pas fonctionner mais tout bloquer... sauf si je désactive un instant le filtrage internet : dans ce cas, les paquets sont (évidemment) autorisés, il y a réponse au ping, et lorsque je réactive le filtrage internet l'instance fonctionne correctement (blocage ou réponse au ping selon le choix, et dans tous les cas signalisation appropriée dans le journal). ... J'espère avoir été plus clair !

A propos de l'autre thread, merci pour les potentielles améliorations du service ! J'ai hâte

Merci,

Renard A.D.

PS : avez-vous pu reproduire le phénomène dont j'ai parlé en post scriptum ou ai-je halluciné ?

 

Bonjour,

Oui, je confirme ce problème, quand on vient d'ajouter des règles ces fonctions ne marchent pas bien.

Cordialement,

Frédéric

 

Si je comprends bien au total il y a 2 problèmes:
1. L'une des interfaces voit les paquets de l'autre
2. L'une des interfaces ne montre pas les alertes, mais filtre bien quand même (autorisant et bloquant les paquets conformément au jeu de règles), jusqua'u moment où le filtrage est désactivé/réactivé, et là les alertes sont affichées.

Pour le 1.: n'avez-vous pas une configuration bridgée ? A quoi sont physiquement reliées les 2 cartes réseau ?

Pour le 2.: avant de désactiver/réactivé le filtrage, pourriez-vous regarder le contenu de la console (je soupçonne un "Watch failed" qui indiquerait effectivement que la signalisation des alertes n'a pas pu être activée pour une raison x). A noter, qu'il est préférable de faire ces tests en ayant démarré complètement l'ordinateur et la session sans aucune instance de Look 'n' Stop démarrée en mode service (histoire d'éviter le mélange avec le pb du service, qui présente justement aussi ce symptôme du" Watch failed").

Merci,

Frédéric

 

Oui, 1 est le sujet du thread. Non seulement une instance voit les paquets de l'autre, mais en plus elle applique ses propres règles. 2 est une aparté constatée pendant ces tests. Cependant, le résumé du 2 est incorrect : tant qu'il n'y a pas désactivation/réactivation du filtrage, tous les paquets sont bloqués (enfin, test sur des pings uniquement), quelles que soient les règles.

Les deux cartes réseau sont liées au switch intégré de la freebox v5 et ne sont pas pontées par Windows.

Après redémarrage des deux instances, à la main :
* Voici la console de 192.168.0.2 :
Look 'n' Stop Version 2.06p2

Driver versions: 5.04 & 4.03
API Driver versions: 6.01 & 5.01
[13:00:55] Firewall Internet Actif
[13:00:55] Firewall Appli Actif
[13:00:56] Ordinateur connecté à Internet sur: 192.168.0.2.
[13:00:56] Security Center registration Ok.
[13:01:21] 1 message Uplink
[13:01:51] 1 message Uplink
[13:01:51] 1 message Uplink
[13:01:53] 1 message Uplink
[13:01:53] 1 message Uplink
[13:01:54] 1 message Uplink
[13:01:54] 1 message Uplink
(messages sans rapport)

* Voici la console de 192.168.0.1 :
Look 'n' Stop Version 2.06p2

Driver versions: 5.04 & 0.00
API Driver versions: 6.01 & 0.00
[13:00:57] Firewall Internet Actif
[13:00:57] Firewall Appli déjà Actif
[13:00:57] Ordinateur connecté à Internet sur: 192.168.0.1.
[13:01:21] 1 message Downlink
[13:01:49] Firewall Internet Inactif <- désactivation
[13:01:50] Firewall Internet Actif <- réactivation
[13:01:51] 1 message Downlink }
[13:01:52] 1 message Downlink }
[13:01:53] 1 message Downlink } <- blocage des pings après désactivation/réactivation
[13:01:54] 1 message Downlink }
[13:01:55] 1 message Downlink }

Merci,

Renard A.D.

 

Ok, tout semble correct, et pas d'erreur comme je pensais, et a priori pas de risque de paquets dupliqués physiquement sur le réseau (je pensais éventuellement à un HUB qui pourrait provoquer cela).
Je ne comprends pas ce qui peut se passer, d'autant plus que tout se passe correctement lors de mes tests.

Dans le test ci-dessus, il semble qu'il y ait eu une alerte juste avant la désactivation/réactivation. J'aurais bien aimé savoir de quel type de paquet il s'agissait. En tout cas ça prouve qu'un filtrage est quand même actif sur cette interface et que les alertes sont bien actives.

Quand une instance voit les 2 pings (sur 192.168.0.1, et 192.168.0.2 et venant de 192.168.0.3). Avez-vous regardé le detail des paquets pour bien vérifier que l'adresse IP de réception est 192.168.0.1 pour certains paquets reçus et 192.168.0.2 pour les autres ?

Que se passe-t-il si une seule instance est lancée (celle qui voit tout en particulier) ?
Est-ce qu'elle continue à tout voir (même après un reboot où elle est la seule à être lancée) ? Ou en fait dans ce cas elle ne voit bien que les paquets qui lui sont destinés (et dans ce cas c'est bien le lancement de la 2ème instance qui perturbe) ?

Enfin un autre test à faire: inverser la sélection de l'interface réseau des 2 instances. Il est préférable de rebooter après cette opération, pour être sûr de redémarrer dans un état propre. Bien vérifier au redémarrage que les sélections ont changé. Dans ces conditions, est ce que le problème suit plutôt l'instance ou plutôt l'interface réseau ?

Le problème vient peut être des noms des interfaces réseau qui seraient identiques, ce qui provoquerait une confusion. Dans la console, appuyez sur "Driver Log" pour afficher ce qu'a vu le driver comme noms d'interfaces (juste à faire sur une seule instance).

Est-ce Look 'n' Stop a été installé alors que les 2 cartes réseau étaient déjà présentes dans l'ordinateur ? (ou est que la 2ème carte réseau a été mise en place alors que Look 'n' Stop était déjà installé)

Désolé de demander tous ces tests et vérifications, je ne vois pas d'autre solution pour avancer.

Merci,

Frédéric

 

Tous les tests ci dessous sont effectués avec les instances lancées manuellement. J'en profite pour signaler un petit souci : lorsque je redémarre la machine, une fois de nouveau sous Windows, le Centre de sécurité croit que "Look'n'Stop 2.06p2 (Soft4Ever)" est lancé alors que ce n'est pas encore le cas (et ce, quelle que soit la présence de BlockAllBeforeInit qui aurait pu passer pour un firewall). En tous cas, après lancement et arret (manuel) des instances, les clés adéquates semblent être mises à jour et on a droit au message d'avertissement.

Il s'agit d'un paquet UDP netbios138 de 192.168.0.2 vers 192.168.0.1 (bloqué).

Hum, vérification intéressante : lors de l'analyse du paquet de réponse de 192.168.0.1 vers 192.168.0.3 qui a été bloqué par 192.168.0.2, on constate que l'adresse IP source est bien 192.168.0.1 et l'adresse IP destination 192.168.0.3 MAIS l'adresse mac source est celle de l'interface associée à 192.168.0.2 ! Je ne vois pas pourquoi, mais ça explique que cette instance et réagit !
Note au passage, j'ai créé une règle in/out, puis une règle in et un règle out. Dans le cas des paquets entre 192.168.0.3 et 192.168.0.1, ce ne sont que les out qui se manifestent dans le journal de 192.168.0.2, et que les in dans le journal de 192.168.0.1. Autre manifestation : si les règles in de 192.168.0.2 et out de 192.168.0.1 (donc celles qui n'arrivent pas à se manifester dans le journal) sont bloquantes, alors elles ne fonctionnent pas. Pourquoi ? C'est peut-etre une piste en tous cas !

Si la seule instance lancée est celle de 192.168.0.2, les symptômes sont les mêmes.
Si la seule instance lancée est celle de 192.168.0.1, les règles de 192.168.0.2 sont bien inactives (règles bloquantes pour ce test).

Hum, bonne idée ! Le problème semble suivre l'interface réseau puisque les pings vers 192.168.0.2 (à présent en mult1) n'ont pas de problème et ceux vers 192.168.0.1 les ont toujours.
Note : je remets les interfaces (et les jeux de règles) comme avant !

Les noms d'interfaces sont bien différents :
DLL:
SelectAdaptOK
T2S
T1S
FW:
Driver Entry Win2k/XP/2003/Vista
Miniport réseau étendu (Moniteur réseau) - Look 'n' Stop Driver
Miniport réseau étendu (IP) - Look 'n' Stop Driver
Carte réseau 3Com EtherLink XL 10/100 PCI pour gestion intégrale de PC (3C905C-TX) - Look 'n' Stop Driver
Marvell Yukon 88E8001/8003/8010 PCI Gigabit Ethernet Controller - Look 'n' Stop Driver
FW1:
ƒTltðjtØ

Oula, bonne question ! Désirez-vous que je désinstalle et réinstalle le logiciel ?

Avec plaisir !

Note au passage : SPF est activé sur les deux instances, cette option est-elle bien gérée interface par interface ?

Puisqu'on est à parler des instances qui ne devraient travailler que pour leur interface, j'ai une question (encore une...) : pourquoi les règles de base proposées dans les fichiers de règles par défaut ne sont pas paramétrées avec des champs "egale à mon @" (pour ethernet ET pour IP) ? Dans le cas des règles bloquantes il est en effet plus prudent de rester général au cas où l'interface recevrait des paquets mal construits (et encore ?) mais pour les autorisations je suis plus perplexe !

Merci !

Renard A.D.

 

Bonjour,

Si Look 'n' Stop n'a pas été lancé une seule fois dans cette session, c'est curieux, car c'est uniquement l'exe qui s'inscrit auprès du centre de sécurité. Il ne me semle pas que Windows conserve cet état d'enregistrement de manière persistante (au reboot).
Parfois le centre de sécurité met vraiment du temps à démarrer et à tout signaler. N'est-ce pas simplement cela ?

Si j'ai bien compris seuls les paquets sortants présentent le problème et les paquets entrants sont bien sur la bonne instance. Et quand on analyse le contenu du paquet tout est cohérent vis à vis des adresses MAC.
Dans ce cas, il s'agit certainement d'une configuration particulière des routes et métriques qui provoque cela, et Look 'n' Stop détecte bien les paquets tels que Windows les fait transiter en interne.
Tout se passe comme si en définitive, l'une des cartes était la passerelle de l'autre carte et donc en émission les paquets passaient d'abord par elle.

C'est cohérent avec le reste.

Les noms sont bien différents, mais de toute façon ce n'était a priori pas le driver qui se mélange les pinceaux dans les interfaces.

Non, pas la peine, pour moi tout est finalement Ok avec l'installation des drivers de Look 'n' Stop.

Oui, chaque instance gère les paquets qu'il voit passer sur son interface.
Seulement si certains échanges IN/OUT utilisent des routes différentes, avec ce qu'on a vu plus haut, ça peut géner.

Les jeux de règles initiaux avaient été créés alors que l'option "égale mon @ MAC" n'existait pas encore. Donc c'est avant tout historique.
Ensuite il faudrait regarder précisément si dans tous les cas l'adresse MAC est censée être celle du PC. Typiquement pour des connexions sans ethernet (modem classique, modem USB ADSL...) l'adresse MAC n'est pas forcément significative.

Cordialement,

Frédéric

 

Bonjour,

J'ai attendu une dizaine de minutes pour confirmer et le Centre de sécurité ouvert (ou plutôt vingt, le temps d'écrire mes messages ). Celui-ci annonce bien "Look 'n' Stop 2.06p2 (Soft4Ever) est actuellement activé. Un pare-feu protège votre ordinateur contre les virus et autres atteintes à sa sécurité." Il ne semble pas qu'il s'agisse d'une initialisation qui traîne mais bien d'un mal entendu du Centre de sécurité, non ? Quelle est la clé à observer pour constater manuellement un mauvais signalement ?

C'est bien ça.

Voici les routes définies. Je n'y connais pas grand chose, mais il ne semble pas qu'il y ait une dépendance entre 192.168.0.1 et 192.168.0.2. Où serait l'erreur ?
===========================================================================
Liste d'Interfaces
0x1 ........................... MS TCP Loopback interface
0x2 ...00 ** ** ** ** ** ...... Marvell Yukon 88E8001/8003/8010 PCI Gigabit Ethe
rnet Controller - Miniport d'ordonnancement de paquets
0x3 ...00 ** ** ** ** ** ...... Carte rÚseau 3Com EtherLink XL 10/100 PCI pour g
estion intÚgrale de PC (3C905C-TX) - Miniport d'ordonnancement de paquets
===========================================================================
===========================================================================
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
0.0.0.0 0.0.0.0 192.168.0.254 192.168.0.1 15
0.0.0.0 0.0.0.0 192.168.0.254 192.168.0.2 5
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.0.0 255.255.255.0 192.168.0.1 192.168.0.1 15
192.168.0.0 255.255.255.0 192.168.0.2 192.168.0.2 5
192.168.0.1 255.255.255.255 127.0.0.1 127.0.0.1 15
192.168.0.2 255.255.255.255 127.0.0.1 127.0.0.1 5
192.168.0.255 255.255.255.255 192.168.0.1 192.168.0.1 15
192.168.0.255 255.255.255.255 192.168.0.2 192.168.0.2 5
224.0.0.0 240.0.0.0 192.168.0.1 192.168.0.1 15
224.0.0.0 240.0.0.0 192.168.0.2 192.168.0.2 5
255.255.255.255 255.255.255.255 192.168.0.1 192.168.0.1 1
255.255.255.255 255.255.255.255 192.168.0.2 192.168.0.2 1
Passerelle par défaut : 192.168.0.254
===========================================================================
Itinéraires persistants :
Aucun
(désolé mais les tabulations ne passent pas sur le forum !)

Merci aussi pour les autres réponses !

Renard A.D.

 

C'est à cause de ces lignes:
192.168.0.0 255.255.255.0 192.168.0.1 192.168.0.1 15
192.168.0.0 255.255.255.0 192.168.0.2 192.168.0.2 5

Par défaut j'avais une métrique de 10 sur les 2 lignes équivalentes, et les pings sont bien envoyés sur la bonne interface.

J'ai mis une métrique de 20 pour l'une des 2 lignes, et du coup les réponses de ping passent par l'autre carte (autrement dit j'ai reproduit le comportement ).

Si je remets tout à 10, ça revient à la normale.

Cordialement,

Frédéric

 

Tout à fait, j'ai aussi constaté cela cet après-midi mais je ne voyais pas comment résoudre le problème sans changer la métrique. En effet, la métrique est le seul moyen que j'ai trouvé pour que les applications (sauf FTP que l'on peut paramétrer) utilisent l'interface 192.168.0.2 et non 192.168.0.1. Lors des tests en réseau local ce sont ces lignes, mais il faudra aussi étendre cette rectification des métriques aux autres routes. Peut-être est-ce possible de spécifier l'interface par défaut d'une autre manière, afin d'égaliser les métriques ?

En tous cas, bien que ce soient ces lignes qui sont incriminées, je suis étonné que la réponse au ping de Windows puisse être faite sur une autre interface que celle pinguée (conformément à la métrique la plus courte) : ça ne me parait pas logique, surtout pour le ping (à la limite d'autres applications...) !

Merci pour vos investigations,

Renard A.D.
PS : une idée pour le Centre de sécurité ?

 

Bonjour,

Je ne sais pas comment est choisie l'interface réseau en cas de métrique identique. Si en mettant des métiques identiques, c'est toujours la même carte qui est choisie, alors peut être suffit-il que vous inversiez l'utilisation des 2 adresses IP.

Non pas d'idée, ça ne passe pas par une clef de la base des registres mais par un appel système venant de l'exe.
Les seules possibilités que je vois sont:
- Look 'n' Stop a quand même été lancé lors de cette session, puis il se serait quitté brutalement sans qu'on le voit, ou alors il est toujours lancé mais invisible (vérifier peut être la liste des process actifs, mais s'il était toujours actif, vous ne pourriez pas lancer une nouvelle instance)
- le mode est en définitive persistant dans Windows, et donc le problème viendrait de la session précédente, et là encore Look 'n' Stop serait quitté brutalement sans avoir le temps de dire à Windows qu'il était désactivé.
Mais aucun problème de ce type remonté à ce jour par d'autres utilisateurs (du coup c'est peut être un effet de bord du service qui lance 2 instances).

Cordialement,

Frédéric

 

Bonjour,

merci pour vos réponses.

Pour les routes et choix de carte, je vais faire comme vous le proposez, en espérant tout de même que Windows ne changera pas d'avis d'une fois à l'autre (tantôt une interface, tantôt l'autre).

En ce qui concerne le Centre de sécurité, tous les tests dont je parlais étaient effectués sans service mais manuel. Je suppose donc qu'il ne s'agit pas d'un lancement-extinction brutal avant la session. J'ai alors cherché en fonction de l'état de LnS (et du Centre de sécurité) avant le redémarrage.
Alors que le Centre de sécurité signalait le "danger" avant redémarrage, après redémarrage il prétendait être protégé mais par le pare-feu Windows. A mon grand étonnement puisque celui-ci était desactivé ! En fait, dans le premier onglet des options du pare-feu windows ("général") celui-ci est bien désactivé mais dans le dernier onglet ("avancé"), il est écrit "Le pare-feu Windows est activé pour les connexions sélectionnées" et les deux l'étaient :-/ ... j'espère que ça n'a perturbé les investigations des autres threads !
En décochant tout ça j'ai pu continuer à faire les tests :
- si Lns était fermé avant fermeture de la session, le centre de sécurité signalait le danger et au redémarrage (après une certaine attente) il s'en souvient.
- si LnS était lancé avant fermeture de la session, le centre de sécurité n'y voit que du feu (). Je suppose donc que c'est une extinction trop rapide à la fermeture de Windows.

Tout cela n'est pas bien grave mais je pensais qu'il était bon de le signaler.

Merci encore,

Renard A.D.

 

Bonsoir,

votre idée quant aux routes semble bien fonctionner. Pour information, j'ai tout de même dû imposer la métrique et non pas la laisser automatique.

Merci beaucoup,

Renard A.D.