First packet isn't syn tcp_flags:syn-ack means - Firewall is considering
this connection from 171.10.1.1 as a new connection but drops it because the
first packet is flagged as 'syn-ack' instead of expected 'syn'. So, what is
going on (this is just like talking to myself - so, some basic stuff but it
always helps to discover the underlying factor/s:
10.0.0.1 initiates a tcp session and sends 'syn' (firewall sees the syn and
initiates 'tcp-start timeout' which I guess should by default be 25 seconds
- used to be 60 seconds in previous version/s)
Firewall is waiting for the 'syn-ack' in response to 'syn' but does not get
anything through the tcp starttimeout' and once the tcp start timeout
expires, the 'syn' is cleared off the table.
And now suddenly after the expiry of the tcp-start-timeout, firewall sees a
packet flagged as 'syn-ack' but now it is surprised - firewall is saying
'why the hell this 172.10.1.1 guy is initiating a tcp session w/ a packet
flagged as 'syn-ack' - that firewall says is not allowed - it therefore
drops it saying 'first packet is not syn'. And now, there are couple of
things one can do:
1. depending upon how much time elapses before you see this 'first packet
isn't syn', you can try to increase the 'tcp start timeout' in policy>global
properties>stateful inspection
2. If you are able to achieve the return packet through by increasing start
timeout, start finding out the cause of delay - for example, does
172.10.1.1knows how to route the packet back to
10.0.0.1, so check route on 172.10.1.1 which may have a default gateway
pointing somewhere but needs a static route back to firewall IP of which is
hanging 172.10.1.1 - primarily what I am saying is that you need to check
why is the packet taking so much time from https/http server - what is wrong
w/ your application?
3. By the way, what is the property "Accept outgoing packets originating
from gateway" set to? Nothing to do w/ the issue perhaps but want to confirm
to add this information to my analysis...
my 2c's.
hth,
Rajeev
On 3/4/07, fico gid <ficohertz AT gmail DOT com> wrote:
Hi there,
Im using ngx R61 a single gateway and this is a new setup.
I have installed the rule as below :
src=10.0.0.1 , dst=171.10.1.1 svc=http/https allow
when i install the rule above the source can't communicate with
destination and i see drops stating the rule is dropped because the
TCP packet out of state. First packet isnt SYN tcp_flags:SYN-ACK.
so what i did was , i disabled the "Drop TCP out of packet" from
Stateful inspection and installed the rule again.
This time i didn't get the above error, instead the traffic is being
dropped by cleanup rule :
Next I did a returning rule as below :
src=171.10.1.1 , dst=10.0.0.1 svc=any allow
now once i installed this, the communication works.
Has anyone experienced this before ? I know this sounds silly but its
happening right now infront of me.. Unless I have missed something.
Please help as Im running out of time.
regards
Fico.
=================================================
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
=================================================
=================================================
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
=================================================
|
