iptables: ESTABLISHED,RELATED but some ACK or RST rejected

I got a server behind a firewall, DNAT on the firewall redirect ports to
it (like www). The server never initiate a connection, so the rules in the
firewall for forwarding packets from the server are:
I accept states ESTABLISHED,RELATED, and for the rest I log and reject:

iptables -A $CHAIN -m state -p tcp -s $IP_SERVER --state ESTABLISHED,RELATED -j ACCEPT
iptables -A $CHAIN -j LOG --log-level DEBUG --log-prefix "IPT $CHAIN REJECT: "
iptables -A $CHAIN -j REJECT

My problem is:

Some packets are not in the state ESTABLISHED,RELATED but seems valid,
like:

Sep 4 14:23:40 brouillard kernel: IPT tap0-fw REJECT: IN=tap0 OUT=ppp0 SRC=192.168.112.179 DST=80.88.128.132 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=64803 DF PROTO=TCP SPT=80 DPT=49260 WINDOW=5792 RES=0x00 ACK FIN URGP=0

I have overs with flags RST or just ACK.

I don't understand why because these packets are related to a connection.

Shure I could forward all packets but I need security.

thanks

--
Emmanuel Chantréau
100% des gens sont dans une minorité de moins de 5% des gens.

Emmanuel CHANTREAU <(E-Mail Removed)> wrote:

> I got a server behind a firewall, DNAT on the firewall redirect ports to
> it (like www). The server never initiate a connection, so the rules in
> the firewall for forwarding packets from the server are:
> I accept states ESTABLISHED,RELATED, and for the rest I log and reject:
>
[...]
> Some packets are not in the state ESTABLISHED,RELATED but seems valid,
> like:
>
> Sep 4 14:23:40 brouillard kernel: IPT tap0-fw REJECT: IN=tap0 OUT=ppp0
> SRC=192.168.112.179 DST=80.88.128.132 LEN=52 TOS=0x00 PREC=0x00 TTL=63
> ID=64803 DF PROTO=TCP SPT=80 DPT=49260 WINDOW=5792 RES=0x00 ACK FIN
> URGP=0
>
> I have overs with flags RST or just ACK.
>
> I don't understand why because these packets are related to a connection.

I've watched something similar. My investigation has shown that
in my case these rejected packets were delayed duplicates which
arrived when the connection did not exist anymore in the connection
tracking engine of the packet filter.

So fire up ethereal and capture traffic until you see such a log
entry above. Then follow the communication in ethereal where the
logged entry stems from and draw your conclusions or post it here.


HTH

Ciao, Horst
--
»When pings go wrong (It hurts me too)« E.Clapton/E.James/P.Tscharn