First Packet isn't SYN

[ikafka]

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. 

[PhoneBoy · Accepted solution]

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

[ikafka]

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. 

[Manish_NCS]

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. 

[the_rock]

@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

[Manish_N]

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. 

[the_rock · Accepted solution]

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...

[Manish_N]

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.

[the_rock]

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

[Itall]

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.

[the_rock]

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

[Itall]

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.

[the_rock]

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

[Itall]

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!

[Manish_N]

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.

[PhoneBoy]

The gateway is seeing what appears to be an "established" connection for which it did not see the initial 3-way handshake.
That is what this error means.
This might require the app that's generating this traffic to be restarted or, if it's a not well-behavied app, an exception might have to be added.
To create an exception, see: https://support.checkpoint.com/results/sk/sk11088 

[Manish_N]

I am not understanding but checkpoint team suggestion is to upgrade the hotfix and after that also there is same issue

[Manish_N]

Also cp tac saying upgrade the base version from 81.0 to 81.10 but still they are not sure if this issue will gone or not.

[the_rock]

I cant even tell you how many times people told me they upgraded and this issue is still the same. In my personal opinion, version of the software has absolutely NOTHING to do with it.

Andy

[the_rock]

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

[ikafka]

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

[the_rock]

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

Andy

[Zolocofxp]

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. 

[the_rock]

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

Andy