Re: iptables et paquets réponses pop3s

Nicolas KOWALSKI a écrit : - fin de la connexion initiée par le serveur distant, FIN: 08:29:12.000665 IP 74.125.79.109.995 192.168.0.1.51542: F 2051:2051(0) ack 444 win 106 nop,nop,timestamp 2547694355 84435379 - mais mon serveur continue à envoyer des choses, le QUIT peut-être:

Re: iptables et paquets réponses pop3s

Pascal Hambourg pascal.m...@plouf.fr.eu.org writes: Donc le côté qui envoie le FIN devrait s'attendre à ce que l'autre côté envoie encore des données avant d'envoyer son propre FIN. Je viens de faire un essai en local (fetchmail vers un pop3s local), et j'obtiens un comportement normal

iptables et paquets réponses pop3s

Bonjour, J'ai quelques règles iptables sur ma machines pour filtrer les requètes entrantes : # iptables-save # Generated by iptables-save v1.4.2 on Thu Mar 4 18:03:12 2010 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [56903:19141251] -A INPUT -i lo -j ACCEPT -A INPUT -s

Re: iptables et paquets réponses pop3s

Nicolas KOWALSKI a écrit : Ce qui m'étonne ce sont les drops visibles dans les logs, qui apparemment concernent les paquets retour des serveur pop3s que j'interroge, alors que iptables est sensé accepter les connexions établies (-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT). La

Re: iptables et paquets réponses pop3s

Le 14672ième jour après Epoch, Nicolas KOWALSKI écrivait: Bonjour, [...] Ce qui m'étonne ce sont les drops visibles dans les logs, qui apparemment concernent les paquets retour des serveur pop3s que j'interroge, alors que iptables est sensé accepter les connexions établies (-A INPUT -m state

Re: iptables et paquets réponses pop3s

Pascal Hambourg pascal.m...@plouf.fr.eu.org writes: Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC=00:40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRC=74.125.77.109 DST=192.168.0.1 LEN=40 TOS=00 PREC=0x00 TTL=53 ID=24852 PROTO=TCP SPT=995 DPT=48882 SEQ=1083545547 ACK=0 WINDOW=0 RST URGP=0 Mar

Re: iptables et paquets réponses pop3s

fra-duf-no-s...@tourde.org (François TOURDE) writes: Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC=00:40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRC=74.125.77.109 DST=192.168.0.1 LEN=40 TOS=00 PREC=0x00 TTL=53 ID=24852 PROTO=TCP SPT=995 DPT=48882 SEQ=1083545547 ACK=0 WINDOW=0 RST URGP=0

Re: iptables et paquets réponses pop3s

Le 14672ième jour après Epoch, Nicolas KOWALSKI écrivait: fra-duf-no-s...@tourde.org (François TOURDE) writes: Ton programme de récupération (fetchmail?) quitte avant d'attendre la fin de la liaison (le paquet RST). Du coup le port 48882 est considéré comme déconnecté, et les paquets de fin

Re: iptables et paquets réponses pop3s

Nicolas KOWALSKI a écrit : Pascal Hambourg pascal.m...@plouf.fr.eu.org writes: Ce sont des TCP RST (reset) qui sont classés - à tort ou à raison - comme INVALID par le suivi de connexion de netfilter. Rien de grave a priori s'il n'y a pas d'effet secondaire. Merci pour ta réponse. Tant

Re: iptables et paquets réponses pop3s

Nicolas KOWALSKI a écrit : Normalement on devrait avoir du FIN depuis mon-serveur puis FIN-ACK depuis le serveur distant, non ? Oui, c'est la façon normale de terminer une connexion TCP. RST ne sert normalement que pour répondre à un paquet TCP inattendu, comme une demande de connexion SYN

Re: iptables et paquets réponses pop3s

Pascal Hambourg pascal.m...@plouf.fr.eu.org writes: Nicolas KOWALSKI a écrit : A priori ce classement a dû être changé dans les dernières versions du noyau, car ces erreurs n'apparaissaient pas en 2.6.26. C'est depuis une mise-à-jour en 2.6.32 (backports) que je vois ces drops. /me fouille

Re: iptables et paquets réponses pop3s

fra-duf-no-s...@tourde.org (François TOURDE) writes: J'imagine que le meilleur moyen de savoir est de faire un dump du traffic, pour être sûr. Mais il se peut que la fermeture de la liaison soit à l'initiative des deux côtés (ton fetchmailer envoie QUIT puis un paquet FIN, ton serveur à