All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Peter Marshall" <peter.marshall@caris.com>
To: Chris Brenton <cbrenton@chrisbrenton.org>
Cc: netfilter <netfilter@lists.netfilter.org>
Subject: Re: RST packets
Date: Mon, 16 Aug 2004 09:17:48 -0300	[thread overview]
Message-ID: <001e01c4838b$0cd6c0f0$49caa8c0@caris.priv> (raw)
In-Reply-To: 1092410257.1664.226.camel@grendel

Thanks for the suggestions ... I will have a look at the mod_jk logs ....

Peter

----- Original Message ----- 
From: "Chris Brenton" <cbrenton@chrisbrenton.org>
To: "Peter Marshall" <peter.marshall@caris.com>
Cc: "netfilter" <netfilter@lists.netfilter.org>
Sent: Friday, August 13, 2004 12:17 PM
Subject: Re: RST packets


On Thu, 2004-08-12 at 12:58, Peter Marshall wrote:
>
> I am having a problem now where I am getting RST packets being blocked
from
> my internal network heading out to the external network.  It looks like
RST
> packets are used to stop a TCP connection when there is a problem.

Per chance do you have a tcpdump trace of the activity? RST's are
usually an indication of one or two problems:
1) One end of the session has stopped responding
2) Connection attempt to a closed port

There are other reasons, but these are the most common. You may want to
investigate why you are seeing the RSTs packets in the first place.
Sounds like the problem might be broken communications.

> The setup is like this:
> I have a web box in my dmz that people connect to.  A mod-jk connection is
> made through my firewall, and the responses are allowed back with the
> standard ESTABLISHED,RELATED allow on the Forward chain.

What errors (if any) are you seeing in mod_jk.log?

> I guess I was wondering why I was getting a bunch of RST packets and also,
> why the firewall was blocking them.  Would they not be part of the
> ESTABLISED-RELATED chain ?

If a valid session has been established, the first issued RST will be
considered part of that session. Netfilter does work this way as I have
confirmed through many a traces. The only reason I can think of for
Netfilter to block the RST is that it does not have a state entry for
the traffic.

> Here are the relevant rules.
> $IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> $IPT -A FORWARD -s $WEB_BOX_IP -I eth1 -j web-int
> $IPT -A web-int -d 192.168.202.168 -p tcp --dport 8009:8020 -j ACCEPT

I assume there are other rules as I *think* mod-jk starts off on 80/TCP.
Also, I thought ports all the way down to 8005 were valid? Check me on
this as its been a while.

> I do have a chain for int-web ... which is used to connect to a webserver
> running on it ..(and it rejects everything else).  This is the chain that
> the RST packet is making it too and is then getting rejected.  However, I
> did not think that the packet should reach this chain as it is related (or
> establised) to the web-int connection ...

This is a pretty clear indication that there is no state entry for the
packet. Again, a trace would help to diagnose this.

> Any suggestions would be greatly appreciated.  My network set up is a DMZ
> between two firewalls.  The web box is in the DMZ.

Not a big fan of this setup as whacking the Web server permits an
attacker to sniff all your inbound and outbound traffic. Greatly prefer
to add a third NIC to the firewall and isolate the system. Just a
personal preference.

HTH,
Chris




  reply	other threads:[~2004-08-16 12:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-11 21:00 RST packets Peter Marshall
2004-08-12 16:58 ` Peter Marshall
2004-08-13 15:17   ` Chris Brenton
2004-08-16 12:17     ` Peter Marshall [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-07-18 14:04 Jan Engelhardt
2005-07-18 14:12 ` Rob Sterenborg
2005-07-18 16:39 ` R. DuFresne
2005-07-18 18:27 ` Jozsef Kadlecsik
2005-07-27  5:28 ` Grant Taylor
2005-07-21  6:43 Jan Engelhardt
2005-07-21  7:42 ` Rob Sterenborg
2005-07-21 10:56 ` Jörg Harmuth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='001e01c4838b$0cd6c0f0$49caa8c0@caris.priv' \
    --to=peter.marshall@caris.com \
    --cc=cbrenton@chrisbrenton.org \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.