Avec XP et une Freebox, j'utilise Kerio comme pare-fau depuis des
années, pas de soucis. J'ai créé des règles en suivant les conseils de
sites webs sur Kerio.
Mais quand je trimbale mon portable, j'ai plusieurs comportements :
- je me branche en RJ45, ça marche
- idem, mais ça marche aléatoirement. C'est à dire que je dévalide
Kerio pour que ça marche, puis le revalide, ça marche un moment, puis
ça ne marche plus, je le dévalide ça remarche etc.
- je me connecte en Wifi, il faut que je dévalide Kerio le temps de
prendre la connexion, ensuite je le valide et ça marche
- idem, mais cemme pour le RJ45, je dois régulièreme,t dévalider
Kerio, ou le laisser tout le temps dévalider.
Je ne sais pas comment extraire les règles de Kerio en texte.
Quelle type de règle pourrait poser un problème ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Stephane Catteau
siger n'était pas loin de dire :
Je ne sais pas comment extraire les règles de Kerio en texte. Quelle type de règle pourrait poser un problème ?
Comme ça sans réelle information je serais tenté de dire que ce sont les requêtes DHCP qui coincent.
Cela dit, il n'y a pas d'options permettant d'avoir des logs ? Ca serait plus parlant si au moins on savait quelle(s) connexion(s) est/sont bloquée(s).
siger n'était pas loin de dire :
Je ne sais pas comment extraire les règles de Kerio en texte.
Quelle type de règle pourrait poser un problème ?
Comme ça sans réelle information je serais tenté de dire que ce sont
les requêtes DHCP qui coincent.
Cela dit, il n'y a pas d'options permettant d'avoir des logs ? Ca
serait plus parlant si au moins on savait quelle(s) connexion(s)
est/sont bloquée(s).
Je ne sais pas comment extraire les règles de Kerio en texte. Quelle type de règle pourrait poser un problème ?
Comme ça sans réelle information je serais tenté de dire que ce sont les requêtes DHCP qui coincent.
Cela dit, il n'y a pas d'options permettant d'avoir des logs ? Ca serait plus parlant si au moins on savait quelle(s) connexion(s) est/sont bloquée(s).
siger
Stephane Catteau a écrit :
siger n'était pas loin de dire :
Je ne sais pas comment extraire les règles de Kerio en texte. Quelle type de règle pourrait poser un problème ?
Comme ça sans réelle information je serais tenté de dire que ce sont les requêtes DHCP qui coincent.
Cela dit, il n'y a pas d'options permettant d'avoir des logs ? Ca serait plus parlant si au moins on savait quelle(s) connexion(s) est/sont bloquée(s).
Si, mais il y a de nombreuses règles, comme je ne sais pas où chercher, il faudrait que je valide les logs partout, j'imagine que ce serait inexploitable. Je me trompe ?
Je n'ai aucune règle qui contient "DHCP"
-- siger
Stephane Catteau a écrit :
siger n'était pas loin de dire :
Je ne sais pas comment extraire les règles de Kerio en texte.
Quelle type de règle pourrait poser un problème ?
Comme ça sans réelle information je serais tenté de dire que ce sont
les requêtes DHCP qui coincent.
Cela dit, il n'y a pas d'options permettant d'avoir des logs ? Ca
serait plus parlant si au moins on savait quelle(s) connexion(s)
est/sont bloquée(s).
Si, mais il y a de nombreuses règles, comme je ne sais pas où chercher,
il faudrait que je valide les logs partout, j'imagine que ce serait
inexploitable. Je me trompe ?
Je ne sais pas comment extraire les règles de Kerio en texte. Quelle type de règle pourrait poser un problème ?
Comme ça sans réelle information je serais tenté de dire que ce sont les requêtes DHCP qui coincent.
Cela dit, il n'y a pas d'options permettant d'avoir des logs ? Ca serait plus parlant si au moins on savait quelle(s) connexion(s) est/sont bloquée(s).
Si, mais il y a de nombreuses règles, comme je ne sais pas où chercher, il faudrait que je valide les logs partout, j'imagine que ce serait inexploitable. Je me trompe ?
Je n'ai aucune règle qui contient "DHCP"
-- siger
Stephane Catteau
siger n'était pas loin de dire :
Cela dit, il n'y a pas d'options permettant d'avoir des logs ? Ca serait plus parlant si au moins on savait quelle(s) connexion(s) est/sont bloquée(s).
Si, mais il y a de nombreuses règles, comme je ne sais pas où chercher, il faudrait que je valide les logs partout, j'imagine que ce serait inexploitable. Je me trompe ?
Seulement les règles de bloquage, du coup, à part deux ou trois mauvaises habitudes de Windows, il ne devrait y avoir qu'une chose dans la période de temps qui t'intéresse et c'est ce qu'il est nécessaire de connaitre pour régler ton problème.
Je n'ai aucune règle qui contient "DHCP"
C'est normal, ce n'est que le nom du protocole. Regarde du côté des ports 67 (sortie) et 68 (entrée), de l'adresse IP de broadcast (255.255.255.255) et comme Windows à la facheuse manie d'attribuer une adresse IP de lui-même en attendant, regarde aussi du côté de la plage d'adresse IP 169.254.0.0/16.
siger n'était pas loin de dire :
Cela dit, il n'y a pas d'options permettant d'avoir des logs ? Ca
serait plus parlant si au moins on savait quelle(s) connexion(s)
est/sont bloquée(s).
Si, mais il y a de nombreuses règles, comme je ne sais pas où chercher,
il faudrait que je valide les logs partout, j'imagine que ce serait
inexploitable. Je me trompe ?
Seulement les règles de bloquage, du coup, à part deux ou trois
mauvaises habitudes de Windows, il ne devrait y avoir qu'une chose dans
la période de temps qui t'intéresse et c'est ce qu'il est nécessaire de
connaitre pour régler ton problème.
Je n'ai aucune règle qui contient "DHCP"
C'est normal, ce n'est que le nom du protocole. Regarde du côté des
ports 67 (sortie) et 68 (entrée), de l'adresse IP de broadcast
(255.255.255.255) et comme Windows à la facheuse manie d'attribuer une
adresse IP de lui-même en attendant, regarde aussi du côté de la plage
d'adresse IP 169.254.0.0/16.
Cela dit, il n'y a pas d'options permettant d'avoir des logs ? Ca serait plus parlant si au moins on savait quelle(s) connexion(s) est/sont bloquée(s).
Si, mais il y a de nombreuses règles, comme je ne sais pas où chercher, il faudrait que je valide les logs partout, j'imagine que ce serait inexploitable. Je me trompe ?
Seulement les règles de bloquage, du coup, à part deux ou trois mauvaises habitudes de Windows, il ne devrait y avoir qu'une chose dans la période de temps qui t'intéresse et c'est ce qu'il est nécessaire de connaitre pour régler ton problème.
Je n'ai aucune règle qui contient "DHCP"
C'est normal, ce n'est que le nom du protocole. Regarde du côté des ports 67 (sortie) et 68 (entrée), de l'adresse IP de broadcast (255.255.255.255) et comme Windows à la facheuse manie d'attribuer une adresse IP de lui-même en attendant, regarde aussi du côté de la plage d'adresse IP 169.254.0.0/16.
Erwann Abalea
Le 04-01-2011, Stephane Catteau a écrit :
siger n'était pas loin de dire :
Je n'ai aucune règle qui contient "DHCP"
C'est normal, ce n'est que le nom du protocole. Regarde du côté des ports 67 (sortie) et 68 (entrée), de l'adresse IP de broadcast (255.255.255.255) et comme Windows à la facheuse manie d'attribuer une adresse IP de lui-même en attendant, regarde aussi du côté de la plage d'adresse IP 169.254.0.0/16.
L'autoconfiguration en 169.254.0.0/16 n'est pas une "facheuse manie de Windows", c'est ce qui est défini par 2 RFC: 3330 et 3927.
C'est plus utile d'avoir une adresse IP sur une machine, au moins pour pouvoir causer avec son réseau local, que rien du tout.
Le 04-01-2011, Stephane Catteau <steph.nospam@sc4x.net> a écrit :
siger n'était pas loin de dire :
Je n'ai aucune règle qui contient "DHCP"
C'est normal, ce n'est que le nom du protocole. Regarde du côté des
ports 67 (sortie) et 68 (entrée), de l'adresse IP de broadcast
(255.255.255.255) et comme Windows à la facheuse manie d'attribuer une
adresse IP de lui-même en attendant, regarde aussi du côté de la plage
d'adresse IP 169.254.0.0/16.
L'autoconfiguration en 169.254.0.0/16 n'est pas une "facheuse manie de
Windows", c'est ce qui est défini par 2 RFC: 3330 et 3927.
C'est plus utile d'avoir une adresse IP sur une machine, au moins pour
pouvoir causer avec son réseau local, que rien du tout.
C'est normal, ce n'est que le nom du protocole. Regarde du côté des ports 67 (sortie) et 68 (entrée), de l'adresse IP de broadcast (255.255.255.255) et comme Windows à la facheuse manie d'attribuer une adresse IP de lui-même en attendant, regarde aussi du côté de la plage d'adresse IP 169.254.0.0/16.
L'autoconfiguration en 169.254.0.0/16 n'est pas une "facheuse manie de Windows", c'est ce qui est défini par 2 RFC: 3330 et 3927.
C'est plus utile d'avoir une adresse IP sur une machine, au moins pour pouvoir causer avec son réseau local, que rien du tout.
siger
Stephane Catteau a écrit :
siger n'était pas loin de dire :
Cela dit, il n'y a pas d'options permettant d'avoir des logs ? Ca serait plus parlant si au moins on savait quelle(s) connexion(s) est/sont bloquée(s).
Si, mais il y a de nombreuses règles, comme je ne sais pas où chercher, il faudrait que je valide les logs partout, j'imagine que ce serait inexploitable. Je me trompe ?
Seulement les règles de bloquage, du coup, à part deux ou trois mauvaises habitudes de Windows, il ne devrait y avoir qu'une chose dans la période de temps qui t'intéresse et c'est ce qu'il est nécessaire de connaitre pour régler ton problème.
OK. Je ferais ça quand je serais à nouveau à l'extérieur de chez moi.
En attendant, je vois que certaines règles bloquantes sont déjà paramétrées pour loguer.
La seule qui est dans le fichier filter.log pour cette journée est une règle nommée IGMP :
Protocole = "other-2" bloque entrées et sorties tous les ports "locaux" et "remote" toutes les adresses "remote" toutes les applications
Ce que je constate : aux heures où je n'étais pas chez moi hier, branché sur un hub en RJ45, les logs indiquent :
Deux variantes sur l'adresse : IGMP.MCAST.NET [224.0.0.22] et 224.0.0.2
Ça fait des années que je ne m'occupe plus de ça, je ne sais donc pas quoi en penser. C'est peut-être normal, et que la règle en cause ne loguait pas, dans ce cas je verrai ça la prochaine fois.
Mais c'est peut-être ça. Qu'en pensez vous ?
Je n'ai aucune règle qui contient "DHCP"
C'est normal, ce n'est que le nom du protocole. Regarde du côté des ports 67 (sortie) et 68 (entrée), de l'adresse IP de broadcast (255.255.255.255) et comme Windows à la facheuse manie d'attribuer une adresse IP de lui-même en attendant, regarde aussi du côté de la plage d'adresse IP 169.254.0.0/16.
Il y a une règle nommée "ports divers" :
Protocole = TCP & UDP bloque entrées une vingtaine de ports "locaux" dont le 68 (je vois aussi le 8080...) tous les ports "remote" toutes les adresses "remote" toutes les applications
Je n'ai rien changé à ça depuis des années.
-- siger
Stephane Catteau a écrit :
siger n'était pas loin de dire :
Cela dit, il n'y a pas d'options permettant d'avoir des logs ?
Ca
serait plus parlant si au moins on savait quelle(s) connexion(s)
est/sont bloquée(s).
Si, mais il y a de nombreuses règles, comme je ne sais pas où
chercher, il faudrait que je valide les logs partout, j'imagine
que ce serait inexploitable. Je me trompe ?
Seulement les règles de bloquage, du coup, à part deux ou trois
mauvaises habitudes de Windows, il ne devrait y avoir qu'une chose
dans la période de temps qui t'intéresse et c'est ce qu'il est
nécessaire de connaitre pour régler ton problème.
OK. Je ferais ça quand je serais à nouveau à l'extérieur de chez moi.
En attendant, je vois que certaines règles bloquantes sont
déjà paramétrées pour loguer.
La seule qui est dans le fichier filter.log pour cette journée est une
règle nommée IGMP :
Protocole = "other-2"
bloque entrées et sorties
tous les ports "locaux" et "remote"
toutes les adresses "remote"
toutes les applications
Ce que je constate :
aux heures où je n'étais pas chez moi hier, branché sur un hub en
RJ45, les logs indiquent :
Deux variantes sur l'adresse :
IGMP.MCAST.NET [224.0.0.22]
et 224.0.0.2
Ça fait des années que je ne m'occupe plus de ça, je ne sais donc pas
quoi en penser. C'est peut-être normal, et que la règle en cause ne
loguait pas, dans ce cas je verrai ça la prochaine fois.
Mais c'est peut-être ça. Qu'en pensez vous ?
Je n'ai aucune règle qui contient "DHCP"
C'est normal, ce n'est que le nom du protocole. Regarde du côté
des
ports 67 (sortie) et 68 (entrée), de l'adresse IP de broadcast
(255.255.255.255) et comme Windows à la facheuse manie d'attribuer
une adresse IP de lui-même en attendant, regarde aussi du côté de
la plage d'adresse IP 169.254.0.0/16.
Il y a une règle nommée "ports divers" :
Protocole = TCP & UDP
bloque entrées
une vingtaine de ports "locaux" dont le 68 (je vois aussi le 8080...)
tous les ports "remote"
toutes les adresses "remote"
toutes les applications
Cela dit, il n'y a pas d'options permettant d'avoir des logs ? Ca serait plus parlant si au moins on savait quelle(s) connexion(s) est/sont bloquée(s).
Si, mais il y a de nombreuses règles, comme je ne sais pas où chercher, il faudrait que je valide les logs partout, j'imagine que ce serait inexploitable. Je me trompe ?
Seulement les règles de bloquage, du coup, à part deux ou trois mauvaises habitudes de Windows, il ne devrait y avoir qu'une chose dans la période de temps qui t'intéresse et c'est ce qu'il est nécessaire de connaitre pour régler ton problème.
OK. Je ferais ça quand je serais à nouveau à l'extérieur de chez moi.
En attendant, je vois que certaines règles bloquantes sont déjà paramétrées pour loguer.
La seule qui est dans le fichier filter.log pour cette journée est une règle nommée IGMP :
Protocole = "other-2" bloque entrées et sorties tous les ports "locaux" et "remote" toutes les adresses "remote" toutes les applications
Ce que je constate : aux heures où je n'étais pas chez moi hier, branché sur un hub en RJ45, les logs indiquent :
Deux variantes sur l'adresse : IGMP.MCAST.NET [224.0.0.22] et 224.0.0.2
Ça fait des années que je ne m'occupe plus de ça, je ne sais donc pas quoi en penser. C'est peut-être normal, et que la règle en cause ne loguait pas, dans ce cas je verrai ça la prochaine fois.
Mais c'est peut-être ça. Qu'en pensez vous ?
Je n'ai aucune règle qui contient "DHCP"
C'est normal, ce n'est que le nom du protocole. Regarde du côté des ports 67 (sortie) et 68 (entrée), de l'adresse IP de broadcast (255.255.255.255) et comme Windows à la facheuse manie d'attribuer une adresse IP de lui-même en attendant, regarde aussi du côté de la plage d'adresse IP 169.254.0.0/16.
Il y a une règle nommée "ports divers" :
Protocole = TCP & UDP bloque entrées une vingtaine de ports "locaux" dont le 68 (je vois aussi le 8080...) tous les ports "remote" toutes les adresses "remote" toutes les applications
Je n'ai rien changé à ça depuis des années.
-- siger
Stephane Catteau
Erwann Abalea devait dire quelque chose comme ceci :
L'autoconfiguration en 169.254.0.0/16 n'est pas une "facheuse manie de Windows", c'est ce qui est défini par 2 RFC: 3330 et 3927.
Je ne dis pas que ce n'est pas conforme du point de vue réseau, juste que ce n'est pas conforme du point de vue du protocole lui-même ;
<RFC 2131> DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to 0. </>
Le "must" n'est pas capitalisé, mais ça peut aussi bien être une typo qu'une difficulté à trouver une autre façon de formuler la phrase. Pour autant, la règle veut, n'est-ce pas ?
Erwann Abalea devait dire quelque chose comme ceci :
L'autoconfiguration en 169.254.0.0/16 n'est pas une "facheuse manie de
Windows", c'est ce qui est défini par 2 RFC: 3330 et 3927.
Je ne dis pas que ce n'est pas conforme du point de vue réseau, juste
que ce n'est pas conforme du point de vue du protocole lui-même ;
<RFC 2131>
DHCP messages broadcast by a client prior to that client obtaining
its IP address must have the source address field in the IP header
set to 0.
</>
Le "must" n'est pas capitalisé, mais ça peut aussi bien être une typo
qu'une difficulté à trouver une autre façon de formuler la phrase. Pour
autant, la règle veut, n'est-ce pas ?
Erwann Abalea devait dire quelque chose comme ceci :
L'autoconfiguration en 169.254.0.0/16 n'est pas une "facheuse manie de Windows", c'est ce qui est défini par 2 RFC: 3330 et 3927.
Je ne dis pas que ce n'est pas conforme du point de vue réseau, juste que ce n'est pas conforme du point de vue du protocole lui-même ;
<RFC 2131> DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to 0. </>
Le "must" n'est pas capitalisé, mais ça peut aussi bien être une typo qu'une difficulté à trouver une autre façon de formuler la phrase. Pour autant, la règle veut, n'est-ce pas ?
Stephane Catteau
siger devait dire quelque chose comme ceci :
Ça fait des années que je ne m'occupe plus de ça, je ne sais donc pas quoi en penser. C'est peut-être normal, et que la règle en cause ne loguait pas, dans ce cas je verrai ça la prochaine fois.
Mais c'est peut-être ça. Qu'en pensez vous ?
C'est du multicast classique, je ne vois vraiment pas comment le bloquage pourrait en arriver aux problèmes de connexion que tu rencontres. Je serais tenté de dire que ces requêtes n'existent que parce que tu as activé la découverte réseau dans Windows, rien de bien dramatique ou de pénalisant.
Il y a une règle nommée "ports divers" :
Protocole = TCP & UDP bloque entrées une vingtaine de ports "locaux" dont le 68 (je vois aussi le 8080...) tous les ports "remote" toutes les adresses "remote" toutes les applications
Je n'ai rien changé à ça depuis des années.
Retire le port 68 de la liste et si le problème venait effectivement de DHCP tes problèmes seront résolus.
siger devait dire quelque chose comme ceci :
Ça fait des années que je ne m'occupe plus de ça, je ne sais donc pas
quoi en penser. C'est peut-être normal, et que la règle en cause ne
loguait pas, dans ce cas je verrai ça la prochaine fois.
Mais c'est peut-être ça. Qu'en pensez vous ?
C'est du multicast classique, je ne vois vraiment pas comment le
bloquage pourrait en arriver aux problèmes de connexion que tu
rencontres. Je serais tenté de dire que ces requêtes n'existent que
parce que tu as activé la découverte réseau dans Windows, rien de bien
dramatique ou de pénalisant.
Il y a une règle nommée "ports divers" :
Protocole = TCP & UDP
bloque entrées
une vingtaine de ports "locaux" dont le 68 (je vois aussi le 8080...)
tous les ports "remote"
toutes les adresses "remote"
toutes les applications
Je n'ai rien changé à ça depuis des années.
Retire le port 68 de la liste et si le problème venait effectivement
de DHCP tes problèmes seront résolus.
Ça fait des années que je ne m'occupe plus de ça, je ne sais donc pas quoi en penser. C'est peut-être normal, et que la règle en cause ne loguait pas, dans ce cas je verrai ça la prochaine fois.
Mais c'est peut-être ça. Qu'en pensez vous ?
C'est du multicast classique, je ne vois vraiment pas comment le bloquage pourrait en arriver aux problèmes de connexion que tu rencontres. Je serais tenté de dire que ces requêtes n'existent que parce que tu as activé la découverte réseau dans Windows, rien de bien dramatique ou de pénalisant.
Il y a une règle nommée "ports divers" :
Protocole = TCP & UDP bloque entrées une vingtaine de ports "locaux" dont le 68 (je vois aussi le 8080...) tous les ports "remote" toutes les adresses "remote" toutes les applications
Je n'ai rien changé à ça depuis des années.
Retire le port 68 de la liste et si le problème venait effectivement de DHCP tes problèmes seront résolus.
