topic Re: First Packet isn't SYN in Firewall and Security Management

First Packet isn't SYN

ikafka — Fri, 22 Sep 2023 10:59:50 GMT

Hi,

I have looked through similiar post here but it is not exactly the same problem, I wanted to open a post.

The 192.168.100.0/24 network is constantly generating traffic. I know this traffic (SCADA generated). I blocked this 192.168.100.0/24 network by writing a rule from the firewall and did not wan to log. I left it as NONE.

But when I look at logs on the firewall, it shows as a drop but it does not match my rule. Anr rule drops without matching. Too many logs are generated. How can I drop this traffic and make it not keep logs?

Screenshot of a log record.

Re: First Packet isn't SYN

PhoneBoy — Fri, 22 Sep 2023 23:37:37 GMT

You can disable these logs via: https://support.checkpoint.com/results/sk/sk102491

Re: First Packet isn't SYN

the_rock — Fri, 22 Sep 2023 23:54:42 GMT

In layman's terms, all that error means, regardless of the firewall vendor used, is literally that 3 way handshake is not completing, why, thats another question. You need to run tcpdump and fw monitor to find out.

To help with the flags, check out this site my colleague made while back, it gives you the command you can copy directly based on the filter (it also uses multiple vendors)

Andy

www.tcpdump101.com

Re: First Packet isn't SYN

ikafka — Tue, 26 Sep 2023 11:35:02 GMT

Thank you for this site. It is a very nice and useful site.

Re: First Packet isn't SYN

ikafka — Tue, 26 Sep 2023 11:37:43 GMT

Thank you @PhoneBoy for your replying. I set it to not log. Sometimes it is necessary to look at such logs. I can open it again when necessary.

Re: First Packet isn't SYN

Zolocofxp — Tue, 26 Sep 2023 15:36:47 GMT

I have experienced this before and every single time, it had to do with asymmetric routing. SYN packet reached the destination host without going through the firewall and SYN-ACK was returning through the firewall.

Re: First Packet isn't SYN

the_rock — Tue, 26 Sep 2023 15:41:02 GMT

Super useful...my colleague made that in his free time over the years.

Andy

Re: First Packet isn't SYN

the_rock — Tue, 26 Sep 2023 15:41:44 GMT

What you said is literally the case 99% of the time.

Andy

Re: First Packet isn't SYN

Manish_NCS — Fri, 02 Aug 2024 07:03:25 GMT

Hello Team,

I need help for this issue.

First Packet isn't SYN

but my case is different because while dropping the packets can not see for which rule it is hitting.

i have attached the documents with issue.

Re: First Packet isn't SYN

the_rock — Fri, 02 Aug 2024 12:57:07 GMT

@Manish_NCS

You need to do what was discussed in the post. Please ensure routing is 100% correct, and also run some basic captures to make sure traffic is ineeed taking the right path. You can refer to syntax from the site my colleague made while back.

https://tcpdump101.com/#

Alternatively, you can use fw monitor -F flag as well. Say fw monitor -F "srcIP,srcport,dstIP,dstport,protocol" and so on, many option are available the other way around, so ie:

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

Protocol can always be 0 and srcport can be 0, as we all know src port is totally irrelevant, what matters is dst port.

If you need help, message me directly.

Best,

Andy

Re: First Packet isn't SYN

Manish_N — Mon, 05 Aug 2024 01:58:46 GMT

Hello

actually, my case is different and there is no routing issue.

let me explain more about this.

the IP 192.168.1.1 is the client IP address and 192.168.1.100 is the EDR IP address.

I have already allow one rule from 192.168.1.1 to 192.168.1.100 so now the user I can see on my EDR for the receiving logs.

the problem is there is no rule from 192.168.1.100 to 192.168.1.1, but still there is many drops' logs between. which I have attached the screenshot.

recently i also updated my hotfix from 58 to 99 , but still the same and I am using R81.0 Version.

Re: First Packet isn't SYN

the_rock — Mon, 05 Aug 2024 10:28:39 GMT

That would definitely NOT be routing issue, agree, as its on the same subnet, so no need for default gateway, as it would be able to arp for each other's MAC address. Maybe you need to check if there is some sort of software installed thats causing that behavior...

Re: First Packet isn't SYN

Manish_N — Fri, 09 Aug 2024 16:22:34 GMT

Still not understanding my point.

The source ip is 10.144.23.5(user Machine )and destination ip is 10.92.56.5(EDR Server)

For this there is rule for 443 and and on edr we can see the user.

My question why from 10.92.56.5 to 10.144.23.5 there are so many drop packets hitting -- for this there is no rule but still there are so many drop packets.

I hope now u are understanding my point.

Re: First Packet isn't SYN

the_rock — Fri, 09 Aug 2024 16:29:12 GMT

Simple network diagram would help. Otherwise, I will just be wild guessing here. First off, you need rule if we are talking different networks, which we definitely are. Second. if you are seeing drops, you need to do basic zdebug and also tcpdump/fw monitor and it will certainly give you better idea.

Andy

Re: First Packet isn't SYN

Itall — Tue, 13 Aug 2024 14:40:05 GMT

First packet isn't SYN is not a routing problem. These errors appear in the log as a result of poorly terminated / unterminated connections on the client side or on the server side (it is a basic inspection of the protocol on the gateway, whether TCP behaves according to the RFC and the TCP 3-way handshake is checked, or the connection from establishment to termination and the entire process including the correct sequences) this usually happens if the client tries to connect to a connection that no longer exists in the connection table on the gateway, because there was no termination. Unfortunately, there are archaic applications that cannot do business with the TCP 3-way handshake and an exception must be made for them (I met such an application not long ago) on versions before R8X, the exception was solved using user.def on the SMC server, since R8X versions I guess it can also be done in the inspection settings via the smart console. Of course
Routing problems, or if asymmetric routing writes spoofing detection into the log, and depending on the settings on the incoming interface, such traffic is either discarded or only detected and allowed, of course if logging is enabled on the interface in the topology.

Re: First Packet isn't SYN

the_rock — Tue, 13 Aug 2024 15:32:41 GMT

I see what you mean, thats valid, but I would not agree with the statement its not a routing problem. From my experience and having been around CP for quite a while, I can tell you this sort of issue turns out to be routing problem at LEAST 70% of the time.

Of course, every instance is different, but captures would always confirm that.

Andy

Re: First Packet isn't SYN

Itall — Wed, 14 Aug 2024 14:36:45 GMT

So, if we are talking about environments where administrators have anti-spoofing turned off, or have anti-spoofing in detect mode without logging, because they are lazy to straighten out routing, then of course the first packet isn't SYN with a drop action can also occur, because there the asymmetry is.

In an environment where the anti-spoofing technique is used in the prevent-log mode, the first indication of asymmetry in routing is a record of spoofing in the log. If the routing is correct in such an environment, it is one of the possibilities (I have encountered all the possibilities from the experience of the NGX R65 version that I started with to the current R81.20):
1/ client - server - application is not TCP RFC compliant (as I wrote)
2/ a defect on the gateway side (CheckPoint already had several such fixes in the past - the last one I experienced related to VPN routing, which cannot be configured too asymmetrically from the administrator's point of view)
3/ transfer of ClusterXL active/standby operation with missed synchronization of connection tables
4/ sometimes the installation of the policy will do it, if the gateway is heavily loaded and the ClusterXL active/standby flaps, again with missed synchronization of the connection tables (I experienced a few years ago with a cluster on appliances that were in a test environment, they were permanently loaded between 50 - 70%. Limited investment in the company).

I guess I didn't fully understand the questioner. I assumed that the questioner has the basic anti-spoofing functionality active (then it would turn out to be spoofing). Compared to competitors, Checkpoint does not play on security and RFC, but actually uses it. That's why I like CheckPoint first in the portfolio of next gen firewalls.

Re: First Packet isn't SYN

the_rock — Wed, 14 Aug 2024 14:55:40 GMT

There are many different factors as to why people may see that message, I wont go into them now, but in all honesty, me personally, I always found that best thing to do is run fw monitor and see where packet is going, thats always best way to trace the traffic.

Anti-spoofing sometimes has to be turned off for totally different reason.

Andy

Re: First Packet isn't SYN

Itall — Thu, 15 Aug 2024 00:55:36 GMT

Neither anything nor anywhere! If the routing is fine, then there is no need to turn off anti-spoofing !! There is no risk or situation that would trigger a blocking situation based on spoof detection! This is just a stupid habit of, for example, Cisco ASA administrators, where it is not played with. If you experienced the necessity of turning off the spoof check, then there was definitely an asymmetry in your network! It's very simple, if I have an interface in the topology where it is 192.168.22.0/24 and the IP 10.10.22.11 wants to communicate from it, it's wrong and if the firewall/network manager allows this, it's a troll, nothing more, nothing less!

Re: First Packet isn't SYN

Manish_N — Thu, 15 Aug 2024 02:18:26 GMT

Yes but it is not allowed but still why there are the first TCP packets is not sync there as drop.

So many drops are there. Specially between these subnet.