hi Crist,
thank you for your assistance.
best regards,
Gabriel
From: Crist Clark <crist.clark AT GLOBALSTAR DOT COM>
Reply-To: Mailing list for discussion of Firewall-1
<FW-1-MAILINGLIST AT AMADEUS.US.CHECKPOINT DOT COM>
To: FW-1-MAILINGLIST AT AMADEUS.US.CHECKPOINT DOT COM
Subject: Re: [FW-1] gfb: th_flags 2 message_info syn packet for established
connection
Date: Fri, 22 Oct 2004 10:28:14 -0700
gabriel borrageiro wrote:
hi Crist,
Surely this is not a good option if, in the client to server's "eye's",
their session is broken and needs to be re-established with initial SYN,
and
the firewall sees the connection as active for the duration of the service
timeout?
It should work fine as long as the client choses a different
source port for its end of the connection. None of this should
be a problem if the client choses a new ephermeral port each
time.
Although this is probably a badly written app, as reseting the client
application process tore down the tcp connection, re-initialized and
worked.
Using a RST to kill a connection is a Bad Thing. Since there
is no acknowledgement of a RST, there is really no way for
the sender of the RST to know if the other end actually killed
off the connection. If it tries to reestablish the connection
using the same source port, it will fail if the other end is
still alive whether or not there is a firewall in the middle.
This case is also a reason why a firewall might want to retain
state on RST connections. If the one end did not receive the
RST, it may still be trying to talk on that TCP. If the firewall
has no state and just drops the segments, you may have to wait
a long time for that end of the connection to time out. However,
if it retains state, the firewall can either allow the segments
through so the other end can RST or spoof a RST itself. This
will close up the connection faster and actually makes the
firewall _more_ transparent.
Perhaps the firewall saw the tcp connection as still open, and no FYN
packets were sent by both sides, yet the application on the client was not
aware that it's host OS had a connection open with time-wait showing in
netstat -an for the connection.
Not sure what difference that would make. The firewall did see
a SYN packet according to your logs. The client did send a SYN.
If it had tried to open a connection that was in TIME_WAIT, it
would have failed and not have sent a SYN.
From: Crist Clark <crist.clark AT GLOBALSTAR DOT COM>
Reply-To: Mailing list for discussion of Firewall-1
<FW-1-MAILINGLIST AT AMADEUS.US.CHECKPOINT DOT COM>
To: FW-1-MAILINGLIST AT AMADEUS.US.CHECKPOINT DOT COM
Subject: Re: [FW-1] gfb: th_flags 2 message_info syn packet for
established
connection
Date: Thu, 21 Oct 2004 11:39:12 -0700
gabriel borrageiro wrote:
greetings friends!
I am getting dropped packets with erro message info "th_flags 2
message_info
syn packet for established connection".
From what I've read about this error on Nokia support "This error
can be
seen when FireWall-1 receives a new connection from a source to a
destination over the same port/service as a connection that was recently
closed with a FIN or RST. FireWall-1 hangs onto these connections until
the
tcpendtimeout is reached".
If a FIN or RST was sent, why is FW1 trying to hang onto these
connections?
It is stopping our client's application from working.
From what I see, the client is trying to re-initialize the application
session, but FW1 is (NG2) is terminating the connection as it is seeying
packets sent with SYN flag when it does not expect to see this over an
ESTABLISHED session. Whilst this is correct, the error condition
seems to
exist only because FW1 has hung onto the session, when the the server
most
likely sent a FIN or RST a while ago.
A TCP isn't really done just because you see both FINs go by. Remember,
the FINs have to be ACKed. For that reason, there exists the TIME_WAIT
state for TCP. In order for the firewall to work properly, it must keep
state on TCP as long as the end points do. The firewall should retain
state on "closed" connections for at least the TIME_WAIT time of the
end points.
--
Crist J. Clark crist.clark AT globalstar DOT com
Globalstar Communications (408) 933-4387
The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above.
If the reader of this e-mail is not the intended recipient, or the
employee or agent responsible to deliver it to the intended recipient,
you are hereby notified that any review, dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this e-mail in error, please contact postmaster AT globalstar DOT com
=================================================
To set vacation, Out-Of-Office, or away messages,
send an email to LISTSERV AT amadeus.us.checkpoint DOT com
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
hi >fw-1-owner AT ts.checkpoint DOT com
=================================================
=================================================
To set vacation, Out-Of-Office, or away messages,
send an email to LISTSERV AT amadeus.us.checkpoint DOT com
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
fw-1-owner AT ts.checkpoint DOT com
=================================================
|
