connexion aléatoire à internet avec Kerio

Le
siger
Bonjour,

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 ?


--
siger
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Stephane Catteau
Le #22984191
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
Le #22984271
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
Le #22984521
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.
Erwann Abalea
Le #22984921
Le 04-01-2011, Stephane Catteau
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.
siger
Le #22985471
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 :

Rule 'IGMP': Blocked: In protocol [2], 192.168.1.1->localhost, Owner:
Tcpip Kernel Driver

Sept variantes sur le dernier chiffre de l'adresse :
1, 3, 6, 7, 9, 27, 125



Et aux heures où j'étais chez moi, ordinateur branché sur une Freebox :

Rule 'IGMP': Blocked: Out protocol [2], localhost->224.0.0.22, Owner:
Tcpip Kernel Driver

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
Le #22986871
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
Le #22986861
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.
Publicité
Poster une réponse
Anonyme