maybe ye need to allow output of rst packet's like:
iptables -A OUTPUT -p tcp --tcp-flags ALL RST -m state --state NEW -j ACCEPT
it worked for me.
Arnoud
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Wilkes
> Sent: Friday, March 01, 2002 11:24 PM
> To: [EMAIL PROTECTED]
> Subject: Re: REJECT --reject-with tcp-reset does not appear
> to send TCP
> RST packet
>
>
> On Fri, Mar 01, 2002 at 02:23:56PM -0600, Seann Herdejurgen wrote:
> > I am trying to filter out the Nimda virus with the following rule:
> >
> > iptables -t filter -A INPUT -i $EXT_IFACE -p tcp -d $IP
> --dport http \
> > -m string --string ".exe?/c+dir" -j REJECT --reject-with tcp-reset
> >
> > My understanding is that when this rule sees a packet matching
> > ".exe?c+dir", it is supposed to send a TCP RST packet back
> to the sender
> > that will close the connection. The packet is being
> blocked, but the
> > TCP RST packet doesn't appear to go out.
> >
> > When I try this in practice, the connection stays in an ESTABLISHED
> > state for about 5 minutes before the connection is dropped. I was
> > working with a friend of mine using tcpdump and it doesn't
> look like a
> > RST packet is actually being sent out. Is this by design, or is my
> > interpretation of the REJECT target wrong?
> >
> > I received one response to use Snort, but that doesn't
> answer why the
> > REJECT target isn't working.
>
> I tried this out with the following simple rules:
>
> $IPT0 = "/usr/local/sbin/iptables -A tcprules -i eth0"
>
> $IPT0 -p tcp --dport 501 -j LOG --log-prefix "Port501a " #1
> $IPT0 -p tcp --dport 501 -j REJECT --reject-with tcp-reset #2
>
> I telneted from the outside in to an internally NATTed machine. Rules
> #1 and #2 kicked off, supposedly sending back a RST. However I didn't
> see it and noticed that I was dropping an outbound packet from my
> internal machine to the outside with a source port of 501.
>
> If I replaced #2 with a DROP then it stopped the packet dead in its
> tracks and didn't get to the internal machine.
>
> I think I have something else wrong with my NAT rules for it to go
> through like that.
>
> Anyway I'll look more into it.
>
> Chris
>