13.4. State Settings

Home Prev	cOS Core 14.00.17 Administration Guide	Next

Max Connections

This setting is used to manually specify the number of simultaneous connections allowed. It only applies if the Dynamic Max Connections setting is disabled (by default, it is enabled). The limit specified in the license cannot be exceeded. Each connection allowed will consume approximately 150 bytes RAM of preallocated connection table storage in memory.

Changes to this setting will be applied as soon as an activate/save sequence is used to apply configuration changes. A restart is not required. However, a change may clear the connection table and all current connections will be dropped.

If the maximum has been exceeded then a connection_table_full log message is generated and the action specified by the setting Connection Replace is followed.

Default: 8192

	Caution: Max Connections changes close all connections
The administrator should assume that a change in the Max Connections setting will reinitialize the connections table. This means that all current connections will be dropped when the change is activated. For this reason, it is recommended to only change the setting at a time when live traffic is at a minimum. This is also true for changes to the Dynamic Max Connections setting which is described next. In an HA cluster, a new maximum will by synced but may still result in all connections being dropped on both nodes. Live traffic should also be minimized when changing the maximum for a cluster.

Caution: Max Connections changes close all connections

The administrator should assume that a change in the Max Connections setting will reinitialize the connections table. This means that all current connections will be dropped when the change is activated. For this reason, it is recommended to only change the setting at a time when live traffic is at a minimum. This is also true for changes to the Dynamic Max Connections setting which is described next.

In an HA cluster, a new maximum will by synced but may still result in all connections being dropped on both nodes. Live traffic should also be minimized when changing the maximum for a cluster.

A general discussion of memory allocation and the effects on memory of Max Connections can be found in a Clavister Knowledge Base article at the following link:

https://kb.clavister.com/324735655

Dynamic Max Connections

This automatically sets the maximum number of allowed simultaneous connections. The maximum value set will almost always be the maximum number of connections allowed by the current license, unless there is a memory constraint.

Changes to this setting will be applied as soon as an activate/commit sequence is used to apply the configuration change. A restart is not required. Changing this setting may, in certain circumstances, cause all current connections to be dropped so having minimal live traffic is recommended.

Default: Enabled

Connection Replace

Allows new additions to the cOS Core connection list to replace the oldest connections if there is no available space.

Changes to this setting will be applied as soon as an activate/commit sequence is used to apply configuration changes. A restart is not required.

Default: ReplaceLog

Log Open Fails

In some instances where the Rules section determines that a packet should be allowed through, the stateful inspection mechanism may subsequently decide that the packet cannot open a new connection. One example of this is a TCP packet that, although allowed by the Rules section and not being part of an established connection, has its SYN flag off. Such packets can never open new connections. In addition, new connections can never be opened by ICMP messages other than ICMP ECHO (Ping). This setting determines if cOS Core is to log the occurrence of such packets.

Default: Enabled

Log Reverse Opens

Determines if cOS Core logs packets that attempt to open a new connection back through one that is already open. This only applies to TCP packets with the SYN flag turned on and to ICMP ECHO packets. In the case of other protocols such as UDP, there is no way of determining whether the remote peer is attempting to open a new connection.

Default: Enabled

Log State Violations

Determines if cOS Core logs packets that violate the expected state switching diagram of a connection, for example, getting TCP FIN packets in response to TCP SYN packets.

Default: Enabled

Log Connections

Specifies how cOS Core, will log connections:

NoLog - New connections will not be logged and therefore it will not matter if logging is enabled for any IP rule set entries that allow new connections. However, logging will still be done according to IP rule set entry settings for any stateless connections (a Stateless Policy or FwdFast IP rule) and for Drop or Reject actions.
Log - Logs connections in short form; gives a short description of the connection, which rule allowed it to be made and any SAT rules that apply. Connections will also be logged when they are closed.
LogOC - As for Log, but includes the two packets that cause the connection to be opened and closed. If a connection is closed as the result of a timeout, no ending packet will be logged
LogOCAll - Logs all packets involved in opening and closing the connection. In the case of TCP, this covers all packets with SYN, FIN or RST flags turned on
LogAll - Logs all packets in the connection.

Default: Log

Log Connection Usage

This generates a log message for every packet that passes through a connection that is set up in the cOS Core state-engine. Traffic whose destination is the Clavister firewall itself, for example cOS Core management traffic, is not subject to this setting.

The log message includes port, service, source/destination IP address and interface. This setting should only be enabled for diagnostic and testing purposes since it generates unwieldy volumes of log messages and can also significantly impair throughput performance.

Default: Disabled