First Packet Isn't SYN drop

[DannyCor]

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?

[the_rock]

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

[AkosBakos]

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

[the_rock]

Routing usually comes to mind with this sort of error.

[DannyCor]

Both dropped and allowed traffic coming from same interface. 

[DannyCor]

I checked them, it uses same interface.

[the_rock]

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

[DannyCor]

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.

[AkosBakos]

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

[Lesley]

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.

[DannyCor]

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

[AkosBakos]

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

[Lesley]

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? 

[AlekzNet]

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

[DannyCor]

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

[AlekzNet]

Here we go. Exactly what I said above.