Reprise du message précédent :

 
Exact on peut pas mettre de -i j'avais oublie desole.
 
On va essayer autre chose juste pour voir.
 
tu mets
 

 
avant tes regles INPUT juste apres les POSTROUTING

Oups, je viens de regarder tes logs et apparemment c'est ce qui est forwarder de ton interface internet vers ton lan qui est droppe.
 
Essaies avec l'inverse

 
TOujours au meme endroit avant tes regles INPUT juste apres les POSTROUTING
 
Si ca marche c'est donc tes regles inet_lan qui merdent. Moi je mettrai les regles de forward avant les regles input et output meme si theoriquement ca n'a pas d'importance.

Bon j'y vais a toute a l'heure

marche toujours pas mais je n'ai plus qu'une ligne dans le log:
 
Jul 26 15:19:41 server kernel: FW DROP IN= OUT=ppp0 SRC=217.128.107.214 DST=224.0.1.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2

Ok bon laisse la derniere regle FORWARD que je t'ai dis de mettre et rajoute celle la juste apres.
 

 
C'est en bonne voie je sens qu'on va y'arriver

Bon j'ai fait la manip (j'ai perdu du temps car j'ai redémarré le serveur et après impossible de se reconnecter au net depuis la station...j'avais oublié de réactiver l'interface réseau de la station car dhcp )
 
Je me retrouve en core avec les 4 log en FW (j'ai différencier les log IN, OU et FW).
 
Mais la manip en fait ne fait rien car le drop se fait de ppp0 vers eth0

T'a bien mis les deux regles que je t'ai donnees juste au dessus juste apres POSTROUTING ?

oui

$IPTABLES -A FORWARD -i$INET_IFACE -o $LAN_IFACE0 -j ACCEPT
$IPTABLES -A FORWARD -i $LAN_IFACE0 -s 192.168.100.0/24 -o $INET_IFACE -j ACCEPT
$IPTABLES -A FORWARD -i $LAN_IFACE0 -o $INET_IFACE -j ACCEPT

autant pour moi    
il manquait un espace sur la première règle entre le i et le inetface.
Là ça marche, c'est ouvert mais ça marche  

 
Bouges pas je reprends a zero ton script.

bobor a écrit a écrit : autant pour moi     il manquait un espace sur la première règle entre le i et le inetface. Là ça marche, c'est ouvert mais ça marche

 
A bon je prefere , donc c'est bien tes regles inet_lan qui merdent.
 
Tu vires les 3 lignes
 

 
tu mets Juste apres tes regles POSTROUTING :
 

 
et dans lan_inet tu remplaces :
 

 
Par
 

 
et dans inet_lan tu remplaces :
 

 
Par
 

là ça marche

Y'a qqun ?

 
Bon ben tout va bien

le $IPTABLES -A inet-lan -j ACCEPT n'est pas nécessaire. Il suffit de mettre un ESTABLISHED, RELATED en ACCEPT. Mais je n'aime pas trop cette méthode car "j'ouvre" des ports

 
 
Ca risque pas grand chose les ESTABLISHED, RELATED car ca veut dire qu'il accepte les connections qui ont ete initiees a l'interieur de ton LAN. Donc si c'est ps toi qui les a initiees d^puis l'interieur ca veut dire que le mec est deja dedans et ca va pas changer grand chose. De plus $Iptables est quand meme repute sur.

 
Pardon c'est pas ACCEPT qu'il faut mettre mais Catch_all
 
( Le copie coller c'est pas toujours bien )

oui mais j'aimerais bien controler au plus juste les stations qui sont sous winchiotte qui ont tendance à "parler" un peu trop à mon gout...
 
Je ne crois pas que ipchains permettait de faire un filtrage sur les state. Comment fait-on avec ipchains pour le ftp?

et si je passe par squid, n'y a-t-il pas moyen de shunter cette règle qui m'énerve?

 
Connais pas squid desole.
 
Pourquoi Ipchain ? Iptables est quand meme mieux non ?

oui oui mais je me demandais quels ports on ouvrait sous ipchains pour mettre en pratique sous iptables

 
Franchement tu vas te faire chier pour rien. T'imagine si dans tes regles de forwarding i faut que tu autorises a chaque fois les ports utilises suite a une connection sur un serveur Web !!!!!
Bon courage . Tres honnetement c'est de la paranoia maladive la !

je te remercie pour ta patience et ton investissement. Je vais rester avec cette règle, je vais tâter squid, et surtout je vais m'occuper des mes invités et des crêpes  

Pas de quoi ca fait toujours plaisir de rendre service