topic First packet is not SYN in Firewall and Security Management

First packet is not SYN

Diw099 — Wed, 27 Mar 2024 11:29:26 GMT

Hi All,

Please find the screenshot attached here, When i checked log from source to destination 185.46.212.88 I don't see any packet drop.

But when checked reverse log its showing drop with error First packet is not SYN.

Please help.

Re: First packet is not SYN

_Val_ — Wed, 27 Mar 2024 11:31:35 GMT

Check the routing in your environment. This is a classic symptom of asymmetric routing.

Re: First packet is not SYN

Chris_Atkinson — Wed, 27 Mar 2024 11:45:24 GMT

Further to @_Val_ suggestion version information for your environment would be helpful...

Re: First packet is not SYN

AmirArama — Sun, 31 Mar 2024 10:54:23 GMT

Is it happens only to this public IP? or it's a general issue? are connections to this IP really never opens? (you can try: 'telnet 185.46.212.88 443' from a workstation) or you just saw such logs and you wonder what that means?

it seems to me that the same origin GW is the one with the SYN, and with the SYN-ACK drop, if that is correct, and the SYN was flowing through it, theoretically it should not drop the SYN-ACK because of assymetry.

can you verify if that is on the same connections though ? it could be completely different connections (the accepted and the dropped).

you can do this by comparing the source IP and src port of the accept log, to the dst port of the blocked log.

for specific test you can do this:

run: tcpdump -nnei ethX host 185.46.212.88

replace ethX with your outgoing interface.

on a separate window run: fw ctl zdebug + drop | grep 185.46.212.88

(please notice that the zdebug can cause high CPU)

then open new connection from a workstation to this IP.

break the tcpdump and the zdebug with ctrl +c , and run: 'fw ctl debug 0' to reset debugging.

see if you got SYN + SYN-ACK on the same connection (verify by the source port+src ip, etc)

see if you have any drop on the zdebug + drop output on that connection (again, compare to the source port, etc)

in case it is the same connection, and syn-ack is dropped, watch what is the time difference between the SYN and the SYN-ACK. if there is some time difference compare it to your "tcp start timeout" in global properties > stateful inspeciton. and verify if the reply returned within the "allowed" time frame or not.

if the syn-ack arrived within the start timeframe and still dropped we should investigate the connection table maybe. but i'm doubt this is the case.

Re: First packet is not SYN

the_rock — Sun, 31 Mar 2024 13:17:31 GMT

What that message means is literally this...3 way handshake is not completing properly and you need to figure out why. I totally agree with what Val said, 9 times out of 10 it has to do with routing.

do this command -> ip r g 185.46.212.88 and make sure it shows correct output

I would also run fw monitor -F command as well, it follows below logic

fw monitor -F "srcip,srcport,dstip,dstport,protocol" and so on, you can do as many -F flags that way, so below is basic example for say src 1.1.1.1 and dst 2.2.2.2 (both ways), port 4434

fw monitor -F "1.1.1.1,0,2.2.2.2,4434,0" -F "2.2.2.2,0,1.1.1.1,4434,0"

All you have to remember is that source port does NOT matter, just dst one and protocol can be 0 for any

hope that helps.

Andy