How does NG handle TCP connections?

The FireWall statefully inspects TCP connections and enforces that they are established via the traditional 3-way handshake. There are three exceptions to this rule of thumb:

1) If you turn on the "fw_allow_out_of_state_tcp" property in the objects_5_0.C (in FP2 this is configurable in the 'advanced' tab of a FireWal1-1 module by un-checking the 'Stateful TCP' check box). This property applies to ALL TCP services and should be turned on with utmost caution since it stops the FireWall from monitoring the state of new TCP connections once the packets pass the rulebase. Enabling this without a good reason is not recommended.

2) In NG FP1 and FP2: FireWall-1 controls connections such as connections needed for policy download, GUI connections, logging connections, etc... can be 'established' in a non-conventional manner.

If a connection does not fall under any of the exception categories, it will be treated as follows:
- The FW will allow it to open and establish via the conventional 3-way handshake, rulebase allowing.
- If the connection expires from the connections table, it's next packet is treated as the 'first' packet of the connection and a 3-way handshake will be enforced - in most cases the connection will not be able to renew itself since it will not try a 3-way handshake session in the middle.
- If a policy load occurs, the connection is NOT removed from the connections table (aside from a few exceptions), but rather set to an 'old' state. To renew a connection in the 'old' state, a packet in the client2server direction must be seen. If a client2server packet reaches the FW, and the new rulebase permits the connection, the connection is renewed and the 'old' state removed. If a server2client packet reaches the FW first, the packet is mangled and sent to the client, prompting an ack from the client back to the server. This ack can be used to renew the connection as previously described. In the case of connection renewal, a 3-way handshake is not enforced since the FW knows the state of the connection so connections that existed prior to the policy reload, and that are allowed by the new policy, should not suffer from any loss of connectivity. The main exception to this is: data connections.

17/MAY/03

< back