Support Center > Search Results > SecureKnowledge Details
How does the Security Gateway handle Established TCP Connections?
Solution

Check Point Security Gateways inspect all IP packets against the Firewall Security Policy. The first packet of each TCP connection or UDP session is checked against the Rule Base. If the first packet is accepted, the connection is added to an internal table of open connections (the connections table), which tracks:

  • Source IP
  • Source Port (if TCP/UDP)
  • Destination IP
  • Destination Port (if TCP/UDP)
  • IP Protocol
  • Encryption Keys
  • Other flags related to the connections

Subsequent packets of an established TCP connection (or UDP session) are checked against the connections table rather than against the Rule Base.

The Security Gateway considers a packet to be part of an established TCP connection if it is not a SYN/NO-ACK packet, that is, if it is not the first packet of TCP connections. You can see the established connections in SecureXL as follows:

gateway[admin]# fwaccel conns

The connection should also be in the regular (F2F) connections table as well:

gateway[admin]# fw tab -t connections -u 

One of the first things the Security Gateway does for each packet is to determine whether the packet's TCP connection (or UDP session) is listed in the connections table (SecureXL and/or F2F). If it is, the packet is immediately accepted (and possibly encrypted or decrypted).

The main advantage to this method is that it is a very efficient way to accept replies to valid TCP connections. Further efficiency is achieved when using SecureXL to accelerate traffic. 

The connections table helps the Security Gateway differentiate between connections originating from A to B and a connection originating from B to A. One may be allowed by the security policy, the other may not. 

Entries are removed from the connections table when one of the following happens:

TCP connections

  • If the TCP connection doesn't complete the 3-way handshake within the TCP Start Timeout (25 seconds, by default).
  • After the TCP End Timeout (20 seconds, by default), which applies after receiving two FIN packets (one in each direction: client-to-server, and server-to-client) or an RST packet. This allows stray ACK packets that belong to the connection, but may arrive late.
  • If the connection is idle (no packets received) for the TCP Session Timeout (3600 seconds, by default)
  • If Aggressive Aging is enabled in the IPS Blade, the Aggressive Aging timeouts will apply if the connection table is near capacity. 
  • If the connection is dropped due a policy violation with one of the Software Blades (e.g. App Control rule or IPS).

UDP sessions

  • If the session is idle (no packets received) for the UDP Virtual Session Timeout (40 seconds, by default).
  • If the connection is dropped due a policy violation with one of the Software Blades (e.g. App Control rule or IPS).

ICMP sessions

  • If the session is idle (no packets received) for the ICMP Virtual Session Timeout (30 seconds, by default).
  • If the connection is dropped due a policy violation with one of the Software Blades (e.g. App Control rule or IPS).

TCP, UDP, and ICMP session timers can be configured in 'Global Properties > Stateful Inspection'. 

When a new Security Policy is installed, this can have an impact on the connections table (both at F2F and SecureXL level), which will impact how established connections are treated. The exact impact will depend on the Connection Persistence setting in the Gateway Object. For more information, refer to sk103598 - Connectivity Issues after Policy Install

Whether entries for existing connections are removed due to exceeding idle timeouts, policy violations, or the result of a new policy installation, the behavior the gateway exhibits when it encounters a packet for an "established" connection is the same. 

The Security Gateway drops TCP packets that claim to belong to established TCP connections (that is, non-SYN and ACK packets) in a special way. The packet is not actually dropped, but instead all the data is removed from the packet, leaving only the IP and TCP headers, which renders the packet harmless. In addition, the TCP header's SEQ number is mangled (that is, the SEQ number is replaced by invalid data).

When A receives the mangled packet, A immediately responds, because of the mangled SEQ number. If the connection is still valid, this response is matched against the Rule Base, and the connection is re-recorded in the connections tables. If the Rule Base indicates that the connection is to be logged, then the packet is logged if "Log Established TCP Packets in the Log and Alert page of the Global Properties window" is checked. The Security Gateway then restarts the timeout clock.

If the connection has become invalid, the packet is dropped. The Security Gateway notices that it is dropping a reply to a mangled TCP packet and so does not mangle it again, but drops it for good.

In rare cases, the Security Gateway logs the mangled packets, if the rule that dropped the packet specified a log action. This means that even if a connection is legal, you might see a drop log entry even though the connection continues. To eliminate these spurious log entries, uncheck "Log Established TCP Packets in the Log and Alert page of the Global Properties window" and reload the Security Policy.

Example

Suppose the Security Policy allows host A to initiate an FTP connection with host B, and specifies that the connection be logged. The log then shows an entry for the first packet, but not for subsequent packets (because the Rule Base is checked only for the first packet). Suppose also that the connection times out.

If the First Packet After the Timeout is Sent by A - If the first packet after the timeout is sent by A, it is handled as though it were the first packet of the connection. The packet is accepted and the timeout clock is restarted. If the Security Policy specifies logging, the packet is logged.

If the First Packet After the Timeout is Sent by B - If the first packet after the timeout is sent by B, the Security Gateway checks the Security Policy. Even if the Security Policy specifies that the packet be dropped or rejected, the Security Gateway mangles the packet and passes it to A. This forces A to request a re-transmission, upon which the Security Policy is checked again, as described above.

Logging a Re-Established TCP Connection

Log Established TCP PacketsB first packet after timeout sent by AB first packet after timeout sent by B
checked packet is logged only if specified by Rule Base - packet is handled exactly as the connection's first packet was handled. packet is logged only if specified by Rule Base (possibly under last "None of the Above" rule).
not checked B packet is not logged. packet is not logged.
Imported from Nokia support database

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment