[j-nsp] " packet dropped, first pak not sync" error message ?

[Stefan Fouant]

On Mon, Dec 1, 2008 at 1:49 PM, Leslie <leslie at craigslist.org> wrote:
> Hi -
>
> I am currently having a very strange issue.  I have a setup that is
> basically a core switch, with ospf enabled and connected to a
> netscreen-isg2000 running screenos 6.0.0r4 . So, I am on a host in the
> cluster, connected to the core switch.  I can ssh to the core switch's ip'ed
> interface that is connected to the netscreen without a problem, but if I try
> to ssh to the loopback, it connects for about 15-20 seconds and then
> disconnects.  I set a flow filter, and got some messages like the ones i
> have pasted below.  It appears that the issue is the netscreen dropping
> packets because of "not sync"  does anyone have any experience with issue
> like this? A quick search just found that the way to "solve" this issue is
> to disable syn flood protection, but I'd prefer to not use that hack.
>
>  packet dropped, first pak not sync

Leslie,

As you have suggested, the reason you are seeing this error is due to
the fact that the firewall is dropping the packets via it's TCP SYN
checking mechanism.  You could disable this via the CLI using the
command 'unset flow tcp-syn-check' however this is not suggested as it
greatly reduces the ability of your firewall to control individual TCP
data flows and prevent SYN flooding.

The likeliest cause for the behavior you are observing is that you
have some form of asymmetrical routing in place in your network.
Flows may be coming in on one interface and then the responses might
be routed out a different interface.  TCP SYN checking essentially
monitors the TCP 3-Way handshake between two end-points attempting to
establish a session.  It will make sure that a SYN, SYN-ACK, and an
ACK are received ON THE SAME INTERFACE prior to creating a session in
the session table and allowing subsequent packets for that session to
be allowed through.  If you can remedy the asymmetric routing you will
most likely fix this problem without having to resort to disabling TCP
SYN checking.

-- 
Stefan Fouant