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

First Packet Isn't SYN drop

DannyCor — Thu, 09 Jan 2025 18:02:27 GMT

I am new to Checkpoint firewall and have been dealing with "First Packet Isn't SYN" issue for the last few weeks. This is happening between interface and one of application server, both server communicate on port 4000. The odd thing I see only first 3 packets are dropped then the 4th allowed to get through.

At the moment, I only have access to logs only, not configuration. Any configuration changes need to be communicated with other team.

Anything place I can start to troubleshoot the issue?

Re: First Packet Isn't SYN drop

the_rock — Fri, 10 Jan 2025 03:30:37 GMT

That can sometimes be bit tricky to troubleshoot. I would say, run tcpdump and fw monitor to see whats happening with the traffic. Also, I would do ip r g command to make sure route is right. Say IP is 10.9.8.7, you can run ip r g 10.9.8.7 from the expert mode.

Hope that helps.

Andy

Re: First Packet Isn't SYN drop

AkosBakos — Fri, 10 Jan 2025 08:59:55 GMT

Hi @DannyCor

If you check the name of the incoming interface at the first packet what do you see? (eg.: eth1)
The interface is the same by that packet which is dropped?

Here is a screenshot what to check:

If not the same, we are facing with asymmetrical routing.

Akos

Re: First Packet Isn't SYN drop

the_rock — Fri, 10 Jan 2025 12:40:29 GMT

Routing usually comes to mind with this sort of error.

Re: First Packet Isn't SYN drop

the_rock — Fri, 10 Jan 2025 15:16:19 GMT

Also, some SKs to consider.

Andy

https://support.checkpoint.com/results/sk/sk107618

https://support.checkpoint.com/results/sk/sk31382

https://support.checkpoint.com/results/sk/sk180253

Re: First Packet Isn't SYN drop

DannyCor — Fri, 10 Jan 2025 15:20:58 GMT

I checked them, it uses same interface.

Re: First Packet Isn't SYN drop

DannyCor — Fri, 10 Jan 2025 15:23:16 GMT

Both dropped and allowed traffic coming from same interface.

Re: First Packet Isn't SYN drop

DannyCor — Fri, 10 Jan 2025 15:27:28 GMT

I wanted to add. Tnterface server is communicating with several different application servers located on multiple different VLANs. This issue only happening on this one particular application server.

Re: First Packet Isn't SYN drop

Lesley — Fri, 10 Jan 2025 16:29:46 GMT

First question is always, are these drops causing any issues? Are there issue reported of this connection flow or you just saw them?

And what is the issue? If they setup new connection is it slow? Or they get timeout after like 1 hour and have to rebuild connection.

Re: First Packet Isn't SYN drop

DannyCor — Fri, 10 Jan 2025 16:43:37 GMT

In my case, it causes encoders not responding to PMS requests cutting room keys.

Re: First Packet Isn't SYN drop

AkosBakos — Fri, 10 Jan 2025 16:46:55 GMT

In this case please check the routing and the interface of the accepted and droppet packet. Itt might help

Re: First Packet Isn't SYN drop

Lesley — Fri, 10 Jan 2025 20:19:13 GMT

Will the request work after some time or they never work? Or it works first few minutes and then stops working after an hour or so?

Re: First Packet Isn't SYN drop

AkosBakos — Mon, 13 Jan 2025 12:04:43 GMT

Check the routing table of the affected server. There will be the problem.

Re: First Packet Isn't SYN drop

AlekzNet — Tue, 14 Jan 2025 21:22:06 GMT

> Or it works first few minutes and then stops working after an hour or so?

Or, does it work "right away', then, if no new traffic is passing, does it work after 1 hour?

"Such things" might happen in, for example, the following cases:

- Asymmetrical routing, when the "reply" packet follows a different path then the "query" one. In this case the connection can not be established.
- New packets after TCP timeout. If there are no packets for 1 hour, the firewall removes the entry from the connection table. If any of the communicating side decides to send more packets, the firewall will drop them with an error "First Packet out of syn".

This can be solved in several ways:
- Just ignore it, if no issues noticed
- Increase the timeout for the service (SmartDashboard)
- Globally increase the TCP timeout for all TCP connections on the firewalls (SmartDashboard)
- Set the TCP heartbeat/keepalives to less than 3600 seconds on the communicating parties (Kernel)
- Configure the firewall to send RST to the parties, when the TCP timeout occurs (Kernel)

Which method to choose - depends on the application, for example, if it can recover from either connection reset or connection timeout.

Re: First Packet Isn't SYN drop

DannyCor — Tue, 14 Jan 2025 21:44:09 GMT

After server reboot, I have seen multiple packets allowed to pass, then after sometimes (hours), the FW starts dropping packets again.

Re: First Packet Isn't SYN drop

AlekzNet — Tue, 14 Jan 2025 21:53:24 GMT

Here we go. Exactly what I said above.