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,
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)
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)
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.
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.
In order to set the option Temporarily (does not survive reboot) the following kernel settings is applied.
- fw ctl set int fw_reuse_established_conn [port_number]
- modzap fw_reuse_established_conn $FWDIR/boot/modules/fwmod.o [port_number]
- Then reboot
- Add the line “fw_reuse_established_conn=[port_number]” to the file $FWDIR/boot/modules/fwkern.conf
- Then Reboot
Further details of changing kernel global parameters can be found within sk26202 (Changing the kernel global parameters on all platforms).
- 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
- How to Configure a BIND Server on Ubuntu - March 15, 2018
- What is a BGP Confederation? - March 6, 2018
- Cisco – What is BGP ORF (Outbound Route Filtering)? - March 5, 2018
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