Issue

The initial SYN packets from your client to your server is being translated by your Firewall into ACK packets which is preventing the initial 3 way handshake establishing.

Below shows you an example :

Inbound:

15:32:19.546115 I 10.1.1.1.12345 > 192.168.1.1.1111: S 2292544025:2292544025(0) win 49640 <mss 1460,nop,wscale 0,nop,nop,sackOK> (DF)
15:32:22.924625 I 10.1.1.1.12345 > 192.168.1.1.1111: S 2292544025:2292544025(0) win 49640 <mss 1460,nop,wscale 0,nop,nop,sackOK> (DF)
15:32:29.684476 I 10.1.1.1.12345 > 192.168.1.1.1111: S 2292544025:2292544025(0) win 49640 <mss 1460,nop,wscale 0,nop,nop,sackOK> (DF)

Outbound:

15:32:19.546791 O 10.1.1.1.12345 > 192.168.1.1.1111: . ack 3336546225 win 49640 (DF)
15:32:22.925787 O 10.1.1.1.12345 > 192.168.1.1.1111: . ack 1868928554 win 49640 (DF)
15:32:29.685355 O 10.1.1.1.12345 > 192.168.1.1.1111: . ack 3910026716 win 49640 (DF)

Cause

This is due to a Check Point feature called Smart Connection Reuse.
When a client tries to establish a new connection to a server on the same port as a previously established connection that the client/server believes is terminated, but that the firewall does not, the firewall tries to determine what state the connection is in by sending an ACK (instead of a SYN).
Dependant on the response to the ACK (from the server) the firewall concludes whether the firewall allows the initial SYN or refuses it.

Do we need this feature ?

Before Smart Connection Reuse was added to the Check Point software package any SYN that came to the firewall which matched an exsisting connection (same source/destination port/ip) would be dropped and a log message of "SYN on Established Connection" would be created.
This feature prevents new connections from being unnecessarily dropped.

What else do I need to know ?

This feature can be useful but certain setups and situatio can cause this feature not to function as per design. Such as,

• The server is not responding to the ACK with a RST which would tell the Firewall this is a new connection and allow it to pass the SYN.
• The servers RST response to the SYN isn’t reaching the Firewall.
• The server/client is not correctly closing down the connection, causing the connection state information on the firewall to remain.
• Another firewall is blocking the ACK or RST.

Solution to Potential Issues

You may find you have a scenerio which fits one of the above points, and ACK packets are leaving the firewall and no response is being given. In which case the inital 3 way handshake is failing.

To allow for the firewall to allow a SYN through a established connection you can set the following kernel global setting :

Set the option Temporarily (does not survive reboot) :

1. fw ctl set int fw_reuse_established_conn [port_number]
   

IPSO

1. modzap fw_reuse_established_conn $FWDIR/boot/modules/fwmod.o [port_number]
2. Then reboot
   

SPLAT

1. Add the line "fw_reuse_established_conn=[port_number]" to the file $FWDIR/boot/modules/fwkern.conf
2. Then Reboot

Further details of changing kernel global parameters can be found below : 

• sk26202 - Changing the kernel global parameters on all platforms
  

References :

• sk33285 - Kernel Global Parameters
• sk39455 - Why does the firewall change certain SYN packets to ACK packets ?
• sk24960 - VPN-1/FireWall-1 NG with AI R54 modifies some SYN packets, and changes them to ACK