> Basically all the answers I got back were somewhat unsatisfactory,
> so I have been made to assume that this is an irritating fact of
> life with the PIX and its treatment of TCP connection teardown.
FWIW, I have seen symptoms of the same problem with various
NetScreen models. I'd say it's "an irritating fact of life" either
with some web server software, with HTTP, with TCP/IP, or. just
possibly, with relativistic universes where information takes non-
zero time to cross distance. Any of these could lead to a packet
from a remote server arriving back at the client's gateway after the
gateway has reasonably concluded that the TCP connection was closed.
(The fact that I've seen it repeatedly from some servers and not at
all from some others suggests to me that it's a server software bug,
or the result of network latencies/retransmissions. One could
probably reduce the incidence of these by lengthening the timeout on
session tear-down, but that could provide a window for acceptance of
spoofed packets and so I expect it to remain "an annoying fact of
life".
None of my experience suggests that there's anything special about
the PIX, except that it's not *hiding* the situation as some firewall
designs might be tempted to do.)
David Gillett
On 8 May 2001, at 14:11, Liudvikas Bukys wrote:
> Regarding the message:
>
> > From: "Daniel Crichton" <[EMAIL PROTECTED]>
> > To: Nazila Mofrad <[EMAIL PROTECTED]>
> > Subject: Re: PIX: What's going on?
> > CC: [EMAIL PROTECTED]
> >
> > On 6 May 2001, at 22:36, Nazila Mofrad wrote:
> >
> > > May 6 17:57:40 PIX %PIX-6-302001: Built outbound TCP connection 4638593 for
> > > faddr INTERNET-HOST/80 gaddr MY-SERVER/2394 laddr MY-SERVER/2394
> >
> > > May 6 17:57:40 PIX %PIX-6-302002: Teardown TCP connection 4638593 faddr
> > > INTERNET-HOST/80 gaddr MY-SERVER/2394 laddr MY-SERVER/2394 duration 0:00:00
> > > bytes 0 (TCP Reset-I)
> >
> > > May 6 17:57:43 PIX %PIX-6-106015: Deny TCP (no connection) from
> > > INTERNET-HOST/80 to MY-SERVER/2394 flags RST
> >
> > > The question is the meaning of the last entry. If the incoming packets to my
> > > server do not pass through PIX (which surely do not), which incoming packet
> > > (with RST Bit on) is denied by PIX?
> >
> > If I'm not mistaken (it's first thing Monday morning so I probably am!) these 3
> > log lines represent:
> >
> > 1. Outbound connection built through PIX from MY-SERVER port 2394 to
> > INTERNET-HOST port 80
> >
> > 2. Connection teardown almost immediately by PIX for MY-SERVER (the
> > TCP Reset-I)
> >
> > 3. Incoming RST packet from INTERNET-HOST for closing of connection is
> > denied as connection has already been closed.
> >
> > I'm guessing that the INTERNET-HOST has sent a RST packet back, MY-
> > SERVER has closed down the connection, the PIX has cleared the
> > connection mapping, but for some reason INTERNET-HOST has resent the
> > RST packet as it did not receive a complete connection close sequence from
> > MY-SERVER. Could be software on MY-SERVER playing up, difficult to tell
> > from this.
>
> I see these a lot. When I first saw them I asked around (both here
> and with some Cisco people), trying to decide whether this indicated
> something unusual (that I should investigate further), or whether
> this is normal.
>
> Basically all the answers I got back were somewhat unsatisfactory,
> so I have been made to assume that this is an irritating fact of life
> with the PIX and its treatment of TCP connection teardown.
>
> Why I don't see more complaints about it, I don't know.
> Either people put up with it (and ignore it in their logs and log
> summaries), or there really is something unusual going on here.
>
> I'd love for someone to explain what I should do to see less of it in
> my logs, but I'm not hopeful.
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
