sur un allow flags S/SA avec un keep state, pdt une forte monte du
traffic, le keep state est devenu inoperant sur un firewall. Pas de
message particulier, si ce n'est que les paquets suivants etaient
refuses.
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
talon
Stephane TOUGARD wrote:
Avec un FreeBSD 4.9 et ipf.
sur un allow flags S/SA avec un keep state, pdt une forte monte du traffic, le keep state est devenu inoperant sur un firewall. Pas de message particulier, si ce n'est que les paquets suivants etaient refuses.
Pas de logs d'erreurs.
Quelqu'un a t'il deja rencontre ce probleme ?
Oui, il en a été question ici, mips en a parlé etc. Il y a certainement encore un bug, contrairement à ce qui est mentionné sur la page web de ipfilter. Quand j'ai vu ce problème, remettre les choses à 0 avec ipf -S si je me souviens bien l'a résolu. Je pense que ça vient de ce qu'ipfilter utilise un hash qui doit se remplir trop vite, apparemment pf (de OpenBSD) qui utilise un arbre va mieux. Note que pf existe pour FreeBSD dans les ports (mais peut être en FreeBSD-5).
--
Michel TALON
Stephane TOUGARD <stephane@unices.org> wrote:
Avec un FreeBSD 4.9 et ipf.
sur un allow flags S/SA avec un keep state, pdt une forte monte du
traffic, le keep state est devenu inoperant sur un firewall. Pas de
message particulier, si ce n'est que les paquets suivants etaient
refuses.
Pas de logs d'erreurs.
Quelqu'un a t'il deja rencontre ce probleme ?
Oui, il en a été question ici, mips en a parlé etc. Il y a certainement
encore un bug, contrairement à ce qui est mentionné sur la page web de
ipfilter. Quand j'ai vu ce problème, remettre les choses à 0 avec ipf -S
si je me souviens bien l'a résolu. Je pense que ça vient de ce
qu'ipfilter utilise un hash qui doit se remplir trop vite, apparemment
pf (de OpenBSD) qui utilise un arbre va mieux. Note que pf existe pour
FreeBSD dans les ports (mais peut être en FreeBSD-5).
sur un allow flags S/SA avec un keep state, pdt une forte monte du traffic, le keep state est devenu inoperant sur un firewall. Pas de message particulier, si ce n'est que les paquets suivants etaient refuses.
Pas de logs d'erreurs.
Quelqu'un a t'il deja rencontre ce probleme ?
Oui, il en a été question ici, mips en a parlé etc. Il y a certainement encore un bug, contrairement à ce qui est mentionné sur la page web de ipfilter. Quand j'ai vu ce problème, remettre les choses à 0 avec ipf -S si je me souviens bien l'a résolu. Je pense que ça vient de ce qu'ipfilter utilise un hash qui doit se remplir trop vite, apparemment pf (de OpenBSD) qui utilise un arbre va mieux. Note que pf existe pour FreeBSD dans les ports (mais peut être en FreeBSD-5).
--
Michel TALON
Arnaud Launay
Le Wed, 11 Feb 2004 19:32:48 +0100, Xavier écrivit:
et/ou Timbuktu. Soit au contraire, que je relance mldonkey. Et à chaque fois, je commente/décomment les entrées correspondantes dans le table de NAT.
Tiens, fais tourner. Ca m'a gonfle la derniere fois, j'ai fini par carrement faire sauter le firewall, c'etait plus simple.
NetBSD 1.6ZI/IP Filter: v3.4.29 (336)
Ah oui, et tes regles de firewall aussi.
XAv - si les gros porcs des majors du disque ressortaient de vrais albums au lieu de la nième compil du very best of de merde, on aurait pas besoin de ça...
Ben si, pour telecharger une merde rigolote pour l'ecouter 3 fois et l'effacer.
Mais c'est vrai qu'il y a des CD de Glenn Miller que j'arrive pas a retrouver en rayon (les lost recordings, par exemple).
Arnaud.
Le Wed, 11 Feb 2004 19:32:48 +0100, Xavier écrivit:
et/ou Timbuktu. Soit au contraire, que je relance mldonkey. Et
à chaque fois, je commente/décomment les entrées
correspondantes dans le table de NAT.
Tiens, fais tourner. Ca m'a gonfle la derniere fois, j'ai fini
par carrement faire sauter le firewall, c'etait plus simple.
NetBSD 1.6ZI/IP Filter: v3.4.29 (336)
Ah oui, et tes regles de firewall aussi.
XAv - si les gros porcs des majors du disque ressortaient de
vrais albums au lieu de la nième compil du very best of de
merde, on aurait pas besoin de ça...
Ben si, pour telecharger une merde rigolote pour l'ecouter 3 fois
et l'effacer.
Mais c'est vrai qu'il y a des CD de Glenn Miller que j'arrive pas
a retrouver en rayon (les lost recordings, par exemple).
Le Wed, 11 Feb 2004 19:32:48 +0100, Xavier écrivit:
et/ou Timbuktu. Soit au contraire, que je relance mldonkey. Et à chaque fois, je commente/décomment les entrées correspondantes dans le table de NAT.
Tiens, fais tourner. Ca m'a gonfle la derniere fois, j'ai fini par carrement faire sauter le firewall, c'etait plus simple.
NetBSD 1.6ZI/IP Filter: v3.4.29 (336)
Ah oui, et tes regles de firewall aussi.
XAv - si les gros porcs des majors du disque ressortaient de vrais albums au lieu de la nième compil du very best of de merde, on aurait pas besoin de ça...
Ben si, pour telecharger une merde rigolote pour l'ecouter 3 fois et l'effacer.
Mais c'est vrai qu'il y a des CD de Glenn Miller que j'arrive pas a retrouver en rayon (les lost recordings, par exemple).
Arnaud.
Stephane TOUGARD
Xavier wrote:
J'ai un problème similaire (connexions qui droppent au bout d'une 1/2 seconde : elles sont ESTABLISHED aux deux bouts -du coup, pas de timeout- mais plus rien ne passe.
Je penche donc plutôt pour un problème de NAT. Stéphane, tu as activé ipnat ?
Non, le firewall gere 5 cartes reseau en routage pur de dur.
-- http://www.unices.org
Xavier wrote:
J'ai un problème similaire (connexions qui droppent au bout d'une 1/2
seconde : elles sont ESTABLISHED aux deux bouts -du coup, pas de
timeout- mais plus rien ne passe.
Je penche donc plutôt pour un problème de NAT. Stéphane, tu as activé
ipnat ?
Non, le firewall gere 5 cartes reseau en routage pur de dur.
J'ai un problème similaire (connexions qui droppent au bout d'une 1/2 seconde : elles sont ESTABLISHED aux deux bouts -du coup, pas de timeout- mais plus rien ne passe.
Je penche donc plutôt pour un problème de NAT. Stéphane, tu as activé ipnat ?
Non, le firewall gere 5 cartes reseau en routage pur de dur.
-- http://www.unices.org
espie
In article , Arnaud Launay wrote:
Mais c'est vrai qu'il y a des CD de Glenn Miller que j'arrive pas a retrouver en rayon (les lost recordings, par exemple).
Ca doit etre quelque part entre la lost Ark, les sources de Windows, la version sans bug de libtool, et les lost tales de Tolkien.
In article <slrnc2ktfl.igt.arnaud@citron.launay.org>,
Arnaud Launay <arnaud@volfoni-brothers.org> wrote:
Mais c'est vrai qu'il y a des CD de Glenn Miller que j'arrive pas
a retrouver en rayon (les lost recordings, par exemple).
Ca doit etre quelque part entre la lost Ark, les sources de Windows, la
version sans bug de libtool, et les lost tales de Tolkien.
Mais c'est vrai qu'il y a des CD de Glenn Miller que j'arrive pas a retrouver en rayon (les lost recordings, par exemple).
Ca doit etre quelque part entre la lost Ark, les sources de Windows, la version sans bug de libtool, et les lost tales de Tolkien.
Marwan Burelle
On Wed, 11 Feb 2004 19:32:48 +0100 (Xavier) wrote:
J'ai pourtant mis l'optin LARGE_NAT dans ip_nat.h, sans effet.
Parce que, évidemment, cela ne se produit que lorsque j'utilise un logiciel... hemmmm.... p2p.
Alors, ça c'est marrant ...
Le nat de mon routeur/modem a quelques problèmes également avec le p2p ...
J'ai un peu l'impression que la quantité (un peu inutile) de connexion n'aboutissant pas de manière satisfaisant (ie la connexion a lieu, mais le pire fini par te jetter ... ) y est pour quelque chose.
En gros, je n'utilise plus que bitorrent, voir plus rien de toute façon ce que je cherche je le trouve ni dans les bacs ni en p2p.
Parce que sinon, rien qu'une requète DNS peut prendre suffisament longtemps pour être en time out ...
On Wed, 11 Feb 2004 19:32:48 +0100
xavier@groumpf.org (Xavier) wrote:
J'ai pourtant mis l'optin LARGE_NAT dans ip_nat.h, sans effet.
Parce que, évidemment, cela ne se produit que lorsque j'utilise un
logiciel... hemmmm.... p2p.
Alors, ça c'est marrant ...
Le nat de mon routeur/modem a quelques problèmes également avec le p2p ...
J'ai un peu l'impression que la quantité (un peu inutile) de connexion
n'aboutissant pas de manière satisfaisant (ie la connexion a lieu, mais
le pire fini par te jetter ... ) y est pour quelque chose.
En gros, je n'utilise plus que bitorrent, voir plus rien de toute façon ce
que je cherche je le trouve ni dans les bacs ni en p2p.
Parce que sinon, rien qu'une requète DNS peut prendre suffisament
longtemps pour être en time out ...
On Wed, 11 Feb 2004 19:32:48 +0100 (Xavier) wrote:
J'ai pourtant mis l'optin LARGE_NAT dans ip_nat.h, sans effet.
Parce que, évidemment, cela ne se produit que lorsque j'utilise un logiciel... hemmmm.... p2p.
Alors, ça c'est marrant ...
Le nat de mon routeur/modem a quelques problèmes également avec le p2p ...
J'ai un peu l'impression que la quantité (un peu inutile) de connexion n'aboutissant pas de manière satisfaisant (ie la connexion a lieu, mais le pire fini par te jetter ... ) y est pour quelque chose.
En gros, je n'utilise plus que bitorrent, voir plus rien de toute façon ce que je cherche je le trouve ni dans les bacs ni en p2p.
Parce que sinon, rien qu'une requète DNS peut prendre suffisament longtemps pour être en time out ...
