View Full Version : Look'n Stop et IPv6
UtZ
July 17th, 2008, 05:29 PM
Bonjour,
Je n'ai malheureusement pas pu faire ma demande sur le sujet déjà abordé ici:
http://www.wilderssecurity.com/showthread.php?t=194551&highlight=Regle+IPV6
J'ai exactement le même problème et je ne souhaiterai pas non plus changer de FW pour autant.
Tout comme le dernier utilisateur ayant sollicité l'auteur de ce sujet, je lui serais éternellement reconnaissant s'il pouvait poster la règle qu'il a créée.
D'avance je vous remercie.
Frederic
July 18th, 2008, 08:06 AM
Bonjour,
Que contient le journal de Look 'n' Stop après avoir constaté que ça ne marchait pas ?
Merci,
Frédéric
UtZ
July 23rd, 2008, 11:38 AM
Bonjour,
Veuillez m'excuser pour mon délai de réponse mais j'ai été en déplacement...
Bien voici un copié collé du journal de LnS:
Tout le reste PC >> Internet
Adresse source Adresse destination Type
-Masquée- ----- 00:07:CB:27:1B:4B ---- IPV6
ICMPV6
136 : Neighbor advertisement
J'ai bien pensé à clique droit "Ajouté règle IPV6..." mais cela ne va pas t'il compromettre la sécurité du PC ? Ne vais-je pas de cette manière ouvrir une brèche ?
Cordialement, et encore une veuillez m'excuser.
Frederic
July 23rd, 2008, 12:16 PM
Bonjour,
Oui, pour IPV6 il faut autoriser certains paquets de type ICMPV6.
Le type 136 et aussi le type 135 sont nécessaires à la gestion du réseau, et il faut donc ajouter les règles correspondantes.
Oui, avec un clic droit sur les alertes, vous pouvez normalement ajouter ces règles facilement. Non, ça ne va pas ouvrir de brèche.
C'est surtout les types 128/129 qui servent au Ping IPV6 (équivalent des types 0/8 en ICMP-IPV4) qu'il faut continuer à filtrer pour être invisible.
Il est possible que les types 133 et 134 soient également nécessaires, vous verrez selon le journal.
Cordialement,
Frédéric
UtZ
July 24th, 2008, 05:54 AM
Bonjour,
J'ai autorisé ces ports, le problème c'est qu'a chaque redémarrage du PC, LnS block ces ports alors qu'ils sont autorisé en entré / Sortie.
Je m'en suis aperçu en désactivant ces règles existantes, après les avoirs à nouveau ajoutées, cela fonctionne ?!
D'ou peut prévenir se problème et comment le résoudre ?
D'avance je vous remercie
PS, je vous laisse les screens rules + journal:
Frederic
July 24th, 2008, 07:20 AM
Bonjour,
Quand vous dites que les ports sont toujours bloqués au redémarrage du PC, parlez-vous des alertes 0 à 5 dans la copie d'écran ci-dessus ?
Merci,
Frédéric
UtZ
July 24th, 2008, 08:00 AM
Absolument.
J'ai trouvé cette alerte, je pense ne l'avoir jamais vu auparavant
IGMP
IGMP.MCAST.NET
et après avoir autoriser à nouveau ses règles pour IPV6 (mais cette fois sans avoir supprimer celles précédemment créer) j'ai ces messages:
24/07/08,14:00:45 U-106 'TCP : Bloque tous les au' 2001:4de0:1::1:1 TCPV6 Ports Dest:nntp Src:1046
24/07/08,14:00:45 U-107 'TCP : Bloque tous les au' 2001:4de0:1::1:1 TCPV6 Ports Dest:nntp Src:1045
24/07/08,14:01:17 U-108 'TCP : Bloque tous les au' 2001:4de0:1::1:1 TCPV6 Ports Dest:nntp Src:1047
24/07/08,14:01:17 U-109 'TCP : Bloque tous les au' 2001:4de0:1::1:1 TCPV6 Ports Dest:nntp Src:1048
24/07/08,14:01:20 U-110 'TCP : Bloque tous les au' 2001:4de0:1::1:1 TCPV6 Ports Dest:nntp Src:1047
24/07/08,14:01:20 U-111 'TCP : Bloque tous les au' 2001:4de0:1::1:1 TCPV6 Ports Dest:nntp Src:1048
24/07/08,14:01:26 U-112 'TCP : Bloque tous les au' 2001:4de0:1::1:1 TCPV6 Ports Dest:nntp Src:1047
24/07/08,14:01:26 U-113 'TCP : Bloque tous les au' 2001:4de0:1::1:1 TCPV6 Ports Dest:nntp Src:1048
24/07/08,14:01:58 U-114 'TCP : Bloque tous les au' 2001:4de0:1::1:1 TCPV6 Ports Dest:nntp Src:1049
24/07/08,14:01:58 U-115 'TCP : Bloque tous les au' 2001:4de0:1::1:1 TCPV6 Ports Dest:nntp Src:1050
24/07/08,14:02:01 U-116 'TCP : Bloque tous les au' 2001:4de0:1::1:1 TCPV6 Ports Dest:nntp Src:1050
24/07/08,14:02:01 U-117 'TCP : Bloque tous les au' 2001:4de0:1::1:1 TCPV6 Ports Dest:nntp Src:1049
24/07/08,14:02:07 U-118 'TCP : Bloque tous les au' 2001:4de0:1::1:1 TCPV6 Ports Dest:nntp Src:1050
24/07/08,14:02:07 U-119 'TCP : Bloque tous les au' 2001:4de0:1::1:1 TCPV6 Ports Dest:nntp Src:1049
Cordialement.
PS: La seule façon que j'ai trouvé pour parer à ce problème:
- Quitter / relance LnS. Quid de la sécurité ? Et pourquoi ?
PS2: la navigation sous IE ou FireFox fonctionne. Par contre, lorsque je lance Outlook express je constate un long moment d'attente et je trouve dans le journal :
Frederic
July 24th, 2008, 08:20 AM
En fait vous avez sélectionné l'attribut journal (le !) pour les nouvelles règles créées (celles qui sont en bas de 1ère copie d'écran).
Ces paquets sont bien autorisés, mais provoquent un affichage dans le journal.
Ils ne sont pas bloqués comme vous pensiez.
Dans la première colonne un + indique que le paquet a été autorisé (par exemple U+0, D+1), et un - que le paquet a été bloqué.
Les nouvelles règles que vous avez créées sont sans l'attribut journal, donc tout est Ok maintenant sur ce point. Vous pouvez toutefois supprimer les 3 règles ICMPV6 Type 135, 136, 134 du bas (celles qui ont le !) qui ne servent plus.
Je ne pense pas que les paquets IGMP soient provoqués par l'utilisation d'outlook express, et vous n'avez normalement pas de règles à ajouter pour ces paquets.
En revanche les autres alertes nntp (protocole Network News Transfer Protocol utilisé pour la lecture des news) explique sans doute les lenteurs sous Outlook Express (si vous lisez des news).
Normalement la règle "TCP : Autorise les services Internet Standards." aurait du accepter les paquets indiqués.
Avez-vous toujours cette règle ? est-elle toujours bien placée devant "TCP : Bloque tous les autres paquets." ?
Si oui et oui, quelle version de Windows utilisez-vous ?
Merci,
Frédéric
UtZ
July 24th, 2008, 04:35 PM
Bonsoir,
J'ai donc gardé les dernières règles par contre j'ai réactivé le journal.
En effet, je vois bien les ICMPV6 autorisées mais je me trouve maintenant confronté avec des TCPV6 avec un port qui ne cesse de changer.
Il est donc inutile d'essayer d'autoriser une telle règle (le port changeant constamment, j'ai tout de même testé)
Je vous joints un screen pour que cela soit plus parlant.
Les 2 règles "TCP :..." sont présentes et je n’y ai jamais touchées
J'ai Windows XP Pro SP2 à jour avec les dernières M à J Microsoft (y compris le Fix DNS)
PS: bizarrement, si je quitte LnS et le relance, je n'ai plus les TCPV6. Mais ma sécurité est compromise, ce n'est donc pas une solution.
Cordialement.
Frederic
July 25th, 2008, 03:53 AM
Bonjour,
En fait le port destinataire est bien toujours le même: nntp (119), utilisé par le lecteur de news. Seul le port source change d'une connexion à l'autre (ce qui est normal).
Vous pouvez donc faire une règle spéciale qui ajoute ce port, et votre sécurité ne sera pas compromise.
Ce qui est curieux c'est que les autres types de connexion standard (web en particulier) marchent, et que le problème se pose juste sur ces paquets nntp.
Il est possible que ce soit l'adresse source du paquet qui ne soit pas égale à votre adresse. Ce que vous pouvez regarder (tant que les paquets nntp sont toujours dans le log), c'est regarder le contenu (en double-cliquant sur une alerte) et vérifier si l'adresse source (IPV6 donc) est la même que celle indiquée dans la page d'accueil de Look 'n' Stop.
Vous dites avoir 2 règles "TCP : Autorise les services Internet Standards.". Normalement il n'y en a qu'une. Que contiennent les 2 règles exactement ?
Merci,
Frédéric
PS: Pour ne pas trop "polluer" le journal, vous pouvez normalement enlever l'attribut journal pour les ICMPV6 type 135 et 136.
UtZ
July 25th, 2008, 06:35 AM
Bonjour,
Je vous remercie pour la rapidité à laquelle vous répondez, surprenant je dois le dire.
Encore une fois, chapeau bas à votre support, tout bonnement irréprochable.
Tout à fait, je n'ai bien qu'une règle "TCP : Autorise les services Internet Standards."
Je me suis mal exprimé. Je voulais simplement dire que je n'avait pas touché les 2 règles concernant ""TCP : Autorise les services Internet Standards." et "TCP : Bloque tous les autres paquets."
Voici ce qu'affiche LnS à l'accueil : **.**.**.*** / fe80::***:****:****:****
Effectivement l'adresse source n'est pas la mienne ! D'ou peut provenir ce problème et comment y remédier ?
J'ai bien évidement masqué les IP. La première étant celle en IPV4 suivi de celle en IPV6.
Je vous mets en attaché les règles appliquées actuellement.
Frederic
July 25th, 2008, 08:26 AM
En fait c'est dans le journal de Look 'n' Stop en regardant le détail d'un paquet de l'une des alertes avec le port dest nntp, qu'il faut regarder si vous retrouvez bien votre adresse IPV6 (fe80::***:****:****:****) dans le champ IP source.
Sinon, essayez juste d'ajouter (avec un clic droit) une règle qui autorise le port nntp. Ca devrait normalement résoudre le problème.
Frédéric
UtZ
July 25th, 2008, 08:36 AM
Je vous viens de vous transmettre le journal dans le message précèdent.
Il y a une erreur que je ne comprends pas:
25/07/08,13:56:02 U-5 'Tout le reste ' 192.88.99.1 IP Protocol:41
Où la source à l'air d'être mon PC et la cible 192.88.99.1 ??
Et bien, malheureusement je ne retrouve pas mon IPV6 dans le log, cela expliquerait les problèmes de connections puisque en quittant LnS je me connecte instantanément.
Mais pourquoi LnS trouve mon IPV6 mais ne l'utilise pas ?
PS: en faisant un IPconfig. Je vois qu'il y a un Teredo Tunneling Pseudo-Interface.
Le problème ne viendrait-il pas de là? Lns serait peut-être perdu car, Mon IPV6 et une couche IPV6 sur IPV4 ?
Et miraculeusement L'une des IPV6 attribuée (car il y en a trois!) est celle contenue dans l'alerte mais alors celle choisis pas LnS ne serait pas la bonne ?
PS : Et bien voilà! Ce que je viens de suggérer s’est produit et cela explique pourquoi cela ne fonctionnait pas auparavant.
En fait, lorsque je quitte LnS et je le relance à ce moment là et à cette seule condition il prends la bonne IPV6 (alors que mon IPV4 reste inchangé) et tout rentre dans l’autre sans ajouter quoique se soit dans les règles.
Serait-il possible de corriger ce problème car pendant que je relance LnS, le PC est exposé aux attaques ?
LnS aurait-il des difficultés à suivre le tunneling.
Cela expliquerait peut être aussi les lenteurs au démarrage que je n'avais pas. LnS "moulinerait" pour faire son choix sur les différentes IPV6 ?
Cordialement.
Frederic
July 25th, 2008, 09:44 AM
Oui, si l'adresse IPV6 ne correspond pas à celle des paquets, c'est pour cela que la règle "TCP : Autorise les services Internet Standards" ne s'applique pas pour autoriser les paquets nntp.
Mais je ne comprends pas pourquoi ceci ne s'appliquerait qu'à Outlook Express. C'est ce que j'ai compris plus haut (la navigation Web était OK, et le problème était juste Outlook Express).
J'avais également compris que la lenteur était dans Outlook Express, mais en fait quand vous disiez "lorsque je lance Outlook express je constate un long moment d'attente et je trouve dans le journal" vous parliez de Look 'n' Stop ?
Est-ce que la première adresse IPV6 affichée correspond quand même bien à l'une des interfaces réseau de la liste affichée par IPConfig ?
Malheureusement j'ai peur que certains paquets utilisent l'une des adresses, et d'autres paquets une autre adresse, donc une correction ne serait pas immédiate.
Si le problème est juste de réussir à autoriser les alertes de type:
"25/07/08,14:22:44 U-282 'TCP : Bloque tous les au' 2001:4de0:1::1:1 TCPV6 Ports Dest:nntp Src:1103"
alors le plus simple reste de créer une règle particulière pour ces paquets avec un clic droit (ce genre de règle ne vérifie pas l'adresse IP source).
Si en définitive même la navigation web et d'autres services sont concernés par le problème (mais on devrait alors avoir d'autres alertes dans le journal, vers le port 80 en particulier), alors oui une solution plus générale devra être apportée. Une solution temporaire peut être d'enlever la vérification sur l'adresse IP source pour la règle "TCP : Autorise les services Internet Standards".
Notez qu'en activant les filtrages persistants dans les options avancées, vous continuez à être protégé même si l'application Look 'n' Stop est stoppée.
Frédéric
keta
August 3rd, 2008, 03:38 PM
bonsoir je possede une freebox v5 en degrouper j'ai activer l'ipv6 desssus, installer sur xp egalement, mais mon adresse es toujours en ipv4 , y a t'il quelque chose a ouvrir sur le parefeu ?
Frederic
August 4th, 2008, 05:58 AM
Bonjour,
Est-ce que ça marche sans Look 'n' Stop lancé ?
Si oui, alors consulter le journal pour voir ce qui est bloqué.
Cordialement,
Frédéric
keta
August 4th, 2008, 06:38 PM
voici le journal mais comment accepter cette regle ?
subut3x
August 5th, 2008, 06:19 AM
Bonjour à tous.
Je passais ici par hasard, et j'avais oublié de fournir ma règle à ajouter pour tous ceux que ça pourrait aider, ce que je fais.
Voici donc la règle IPV6 (http://www.wilderssecurity.com/attachment.php?attachmentid=201992&d=1217942567) (fait maison) à ajouter dans LooknStop.
Cependant quelqu'un pourrait confirmer l'état de sécurité de celui-ci svp?
En espérant vous avoir aidé. ;)
Cordialement.
Frederic
August 5th, 2008, 08:10 AM
Bonjour,
La règle proposée ouvre tout IPV6 sans discernement, donc ce n'est pas très sécurisé.
Normalement il suffit juste d'accepter quelques paquets ICMPV6 (types 133 à 136) pour que IPV6 soit opérationnel.
Il suffit de faire cela avec un clic droit sur l'une des lignes du journal montrant une telle alerte (ICMPV6 Type 13x).
Il faut avoir installé la version 2.06p3 (http://www.wilderssecurity.com/showthread.php?t=216026) (ou 2.06p2) pour que l'ajout de règles automatique sur IPV6 marche correctement.
J'aurais bien aimé voir le reste des alertes (cachées par la boite de dialogue) il semble qu'il y ait d'autres blocages que ICMPV6.
Cordialement,
Frédéric
keta
August 5th, 2008, 12:58 PM
je viens de mettre la version 2.06p3. probleme resolu. J'ai mis la regle pour 'ipv6
Par contre une liste impressionnante, je ne c'est ce que c'est
Frederic
August 5th, 2008, 05:39 PM
Ces paquets signifient que vous recevez des paquets sur un port inaccessible.
Soit vous utilisez un logiciel P2P, ou alors vous avez récupéré l'adresse IP de quelqu'un qui utilisait un logiciel P2P.
Si tout est Ok par ailleurs, le mieux est de bloquer ces paquets sans créer d'alerte, avec une règle spéciale. Toujours avec un clic droit vous pouvez créer une règle, mais ensuite activez le sens interdit pour cette nouvelle règle (contrairement aux autres règles créées).
Frédéric
dedef
October 19th, 2008, 08:05 AM
Bonjour,
J'essaye de faire fonctionner mon pc en IPV6 avec looknstop 6p3 :
- vista
- freebox en mode routeur
- règles lns évoluées
- interface réseau en sélection auto
- adresse IP de mon PC supprimée de l'auto-détection dans les options avancées.
Pour que je sois reconnu sur le site : http://www2.surfnet.nl/ipv6/,
j'ai dû ajouter la règle ipv6 jointe :
- ethernet type ipv6
- paquets entrants et sortants
- tous ou toutes pour tout le reste.
Mes questions :
- n'est-elle pas trop permissive,
- faut-il y la limiter à certains programmes (firefox, ...)
- faut-il la laisser en tête.
Voici ce que j'obtiens quand cette règle est en application et que je vais sur le site évoqué ci-dessus.
19/10/08,13:47:02 U+1783 'IPV6 ' ff02::1:ff32:ad40 ICMPV6 Type:135 Code:0
19/10/08,13:47:02 D+1784 'IPV6 ' fe80::207:cbff:fe32:ad40 ICMPV6 Type:136 Code:0
19/10/08,13:47:02 U+1785 'IPV6 ' 2001:610::800a:b192:87:5:121 TCPV6 Ports Dest:www-http=80 Src:53245
19/10/08,13:47:02 D+1786 'IPV6 ' 2001:610::800a:b192:87:5:121 TCPV6 Ports Dest:53245 Src:www-http=80
19/10/08,13:47:02 U+1787 'IPV6 ' 2001:610::800a:b192:87:5:121 TCPV6 Ports Dest:www-http=80 Src:53245
19/10/08,13:47:02 U+1788 'IPV6 ' 2001:610::800a:b192:87:5:121 TCPV6 Ports Dest:www-http=80 Src:53245
19/10/08,13:47:02 D+1789 'IPV6 ' 2001:610::800a:b192:87:5:121 TCPV6 Ports Dest:53245 Src:www-http=80
19/10/08,13:47:02 D+1790 'IPV6 ' 2001:610::800a:b192:87:5:121 TCPV6 Ports Dest:53245 Src:www-http=80
19/10/08,13:47:02 U+1791 'IPV6 ' 2001:610::800a:b192:87:5:121 TCPV6 Ports Dest:www-http=80 Src:53245
19/10/08,13:47:02 D+1792 'IPV6 ' 2001:610::800a:b192:87:5:121 TCPV6 Ports Dest:53245 Src:www-http=80
19/10/08,13:47:02 U+1793 'IPV6 ' 2001:610::800a:b192:87:5:121 TCPV6 Ports Dest:www-http=80 Src:53245
19/10/08,13:47:02 D+1794 'IPV6 ' 2001:610::800a:b192:87:5:121 TCPV6 Ports Dest:53245 Src:www-http=80
19/10/08,13:47:02 U+1795 'IPV6 ' 2001:610::800a:b192:87:5:121 TCPV6 Ports Dest:www-http=80 Src:53245
19/10/08,13:47:07 U+1796 'IPV6 ' fe80::207:cbff:fe32:ad40 ICMPV6 Type:136 Code:0
19/10/08,13:47:07 D+1797 'IPV6 ' fe80::207:cbff:fe32:ad40 ICMPV6 Type:135 Code:0
19/10/08,13:47:17 U+1798 'IPV6 ' 2001:610::800a:b192:87:5:121 TCPV6 Ports Dest:www-http=80 Src:53245
19/10/08,13:47:17 D+1799 'IPV6 ' 2001:610::800a:b192:87:5:121 TCPV6 Ports Dest:53245 Src:www-http=80
19/10/08,13:47:17 U+1800 'IPV6 ' 2001:610::800a:b192:87:5:121 TCPV6 Ports Dest:www-http=80 Src:53245
19/10/08,13:47:17 D+1801 'IPV6 ' 2001:610::800a:b192:87:5:121 TCPV6 Ports Dest:53245 Src:www-http=80
Merci d'avance.
Frederic
October 19th, 2008, 12:12 PM
Bonjour,
La règle indiquée est trop permissive. Elle n'est normalement pas nécessaire, la règle "TCP : Autorise les services Internet Standards." des jeux de règles standards est compatible IPV6 et doit permettre d'autoriser les paquets du journal que vous indiqués (ceux de la règle IPV6).
Notez que pour les règles qui autorisent des paquets (et notamment les règles indiquées dans l'extrait du journal) il ne faut normalement pas indiquer l'attribut journal, de manière à avoir dans le journal juste les blocages (qui sont la source de problèmes éventuels).
En l'occurrence, le journal indiqué est tout à fait normal, pas d'anomalie sur ces paquets autorisés.
Cordialement,
Frédéric
dedef
October 19th, 2008, 01:35 PM
Bonsoir et merci de ces éléments,
Si je supprime ma règle, cela ne fonctionne plus.
J'ai joint la règle "autorise les services internet standard" issue des règles évoluées : je ne crois pas l'avoir modifiée.
Quand j'eesaye de me connecter au site ipv6 de test, ça ne fonctionne pas et je n'ai rien dans le journal!
Frederic
October 19th, 2008, 02:05 PM
Dans ce cas (s'il n'y a rien dans le log quand ça ne marche pas, sans la règle que vous avez ajoutée) c'est qu'il y a une règle qui bloque sans enregistrer les paquets dans le journal.
Essayez d'activer le journal pour les règles bloquantes, normalement le journal devrait alors indiquer des paquets, ce qui permettra d'en savoir plus.
Frédéric
dedef
October 19th, 2008, 03:27 PM
J'ai activé le journal (point d'exclamation) pour toutes les règles bloquantes (sens interdit?):
une seule information dans le journal :
9/10/08,21:16:29 D-2949 'Tout le reste ' fe80::207:cbff:fe32:ad40 ICMPV6 Type:134 Code:0
J'ai donc créé la règle correspondante. Ca n'a pas marché mais j'ai obtenu ça dans le journal :
19/10/08,21:21:08 U-2955 'UDP : Bloquer UPnP/1900 ' 239.255.255.250 UDP Ports Dest:SSDP/UPnP=1900 Src:52207
J'ai alors créé la nouvelle règle correspondante. Ca n'a pas marché mais j'ai obtenu ça dans le journal :
19/10/08,21:22:29 U-2956 'UDP : Stopper le NetBios' 192.168.0.255 UDP Ports Dest:netbios-dgm=138 Src:netbios-dgm=138
J'ai finalement créé la nouvelle règle correspondant et je n'ai plus rien obtenu dans le journal ..., mais ça n'a toujours pas marché!!
Frederic
October 20th, 2008, 04:52 AM
{QUOTE-> J'ai activé le journal (point d'exclamation) pour toutes les règles bloquantes (sens interdit?):
une seule information dans le journal :
9/10/08,21:16:29 D-2949 'Tout le reste ' fe80::207:cbff:fe32:ad40 ICMPV6 Type:134 Code:0
J'ai donc créé la règle correspondante. Ca n'a pas marché [...]
<-QUOTE}
Ca aurait du être l'origine du problème. Si vous avez créé une règle automatique via le journal, vérifiez qu'elle est bien correcte (il y a eu une correction récemment sur ce point). Ceci dit si ce genre d'alerte n'apparait plus ensuite dans le journal c'est sans doute OK.
Peut être vaut-il mieux redémarrer l'ordinateur pour que ce genre de paquets soient autorisés dès le début.
{QUOTE->
[...] mais j'ai obtenu ça dans le journal :
19/10/08,21:21:08 U-2955 'UDP : Bloquer UPnP/1900 ' 239.255.255.250 UDP Ports Dest:SSDP/UPnP=1900 Src:52207
J'ai alors créé la nouvelle règle correspondante. Ca n'a pas marché mais j'ai obtenu ça dans le journal :
19/10/08,21:22:29 U-2956 'UDP : Stopper le NetBios' 192.168.0.255 UDP Ports Dest:netbios-dgm=138 Src:netbios-dgm=138
J'ai finalement créé la nouvelle règle correspondant et je n'ai plus rien obtenu dans le journal ..., mais ça n'a toujours pas marché!! <-QUOTE}
Ces deux derniers types de paquets ne sont pas IPV6 et ne sont donc pas liés au problème (car votre règle IPV6 générique et globale suffit à résoudre le problème). Normalement pas la peine d'ajouter ces règles (vous pouvez cependant les laisser temporairement pour avoir un journal plus propre, tant que le problème n'est pas complètement résolu).
Donc en résumé: après avoir ajouté et vérifié la règle ICMPV6 Type:134 puis redémarré l'ordinateur, et en laissant les alertes sur les paquets qui bloquent (ceux qui ont le sens interdit), est-ce que ça marche, et si non, que contient à nouveau le journal ?
Frédéric
UtZ
October 20th, 2008, 03:21 PM
Pour en revenir à mon problème (cela fait un petit moment, mais mieux vaut tard que jamais et j’ai voulu être sûre de mes dires et observations),
Il est partiellement résolu:
Règles Evoluées modifiées autorisant IPV6 port 134-136.
En installant le SP3 de Windows XP PRO, LnS me sélectionne automatiquement la bonne IPV4 / IPV6. (Sans que cela soit au petit bonheur la chance).
Le ralentissement au démarrage quand à lui persiste.
Cela semble lié au passage IPV6 car en mode IPV4, point de ralentissement.
J'ai tenté vainement, à maintes reprises, à l'aide du journal, de repérer Blocages ou autres erreurs... sans succès.
Je tenais encore une fois en remercier chaleureusement Frédéric pour sa patience et courtoisie.
Encore Merci.
dedef
October 20th, 2008, 03:25 PM
Bonsoir à tous,
Très surprenant : ce soir j'ai accès à l'IPV6 sans ajouter aucune règle spécifique!!
Peut-être le fait d'avoir éteint mon ordinateur a-t'il tout remis d'aplomb!!
Pour le moment je considère donc le problème réglé.
Merci beaucoup à Fréderic.
vBulletin® Copyright ©2000-2009, Jelsoft Enterprises Ltd.