Keeping track of previously allowed rules.

As told in the rule fields and TCP/IP overview, when adding a new rule to allow a packet to reach our machine or to leave it, the response which might come back will have the destination and source fields inverted, speaking about both the internet addresses and ports.
Suppose we allow packets from us to 158.110.28.25 port 80 (i.e. web service). The new rule would contain 158.110.28.25 as destination address and 80 as destination port, and will be an output rule, applying to the tcp protocol. When the web server running at 158.110.28.25 sends back a response to us, we need another rule to allow a packet with 158.110.28.25 as source address come in. Instead of inserting two rules for only one flow, we can enable the stateful connection for that rule. In this case, when the first packet towards 158.110.28.25, port 80, has gone out, the kernel firewall creates a table to remember the just allowed connection. When a response comes back, fields are checked, but the source address and port are compared with the destination ones and viceversa. The maximum number of connections which can be managed by the state machine can be tuned by the administrator acting on the configuration file of IPFIREwall. Remember also that each state table has a timeout after which it's deleted from the kernel lists.
Information about the maximum number of entries allowed for each list and the memory needed by a state table can be recalled from the main menu pressing the C key. When the number of maximum connection tables permitted is reached, a message is printed out on the system log. The current state tables allocated in kernel space are listed if the F5 key is pressed in the main menu. The request is forwarded to the kernel which sends back the state tables set.
The administrator should remember that the connection tables dynamically allocated remain alive after the user interface is turned off until their lifetime is decayed. To remove them immediately, the kernel module should be unloaded, or the option -rmmod should be given at startup. This option, available only for root, actually removes the kernel module after that the user interface goes down.
As one can see in many scenarios, tcp connection reports are logged with a blue keyword that represents the state of the connection. This is a feature not well tested, so it wouldn't have to be trusted very much... In particular, when analyzing a connection already setup, it is not easy for IPFIRE to determine its state. Take it as a simple indication, possibly not correct.