Check Point is changing SYN packets to ACKs ?

Issue

The initial SYN packets from your client to your server are  translated by your Firewall into ACK packets. This in turn  prevents the initial 3 way handshake establishing.

Below shows 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).
Dependent 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

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

To allow for the firewall to allow a SYN through a established connection the following kernel global setting should be applied.

Temporarily

In order to set the option Temporarily (does not survive reboot) the following kernel settings is applied.

  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 within 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
Rick Donato
Latest posts by Rick Donato (see all)

Want to become an IT Security expert?

Here is our hand-picked selection of the best courses you can find online:
Internet Security Deep Dive course
Complete Cyber Security Course – Hackers Exposed
CompTIA Security+ (SY0-601) Certification Complete course
and our recommended certification practice exams:
AlphaPrep Practice Tests - Free Trial