Description

All native Kernun Firewall applications use a special mechanism for network operations called netio. Its goal is to unify the processing, logging and configuring of network operations. Several attributes of the netio library can be set in each application, configured in the same way (see netio(5) for details).

When connecting to remote sites, it is possible to tell netio to use other than the default operating system connection timeout (75 seconds on most systems). This is done using the configurable parameter conn-timeout (expressed in seconds, default value 75). The conn-timeout parameter is relevant only if the socket connection is initiated by the firewall. This is typically the case of server sockets (clients issue their connections to firewall themselves).

For both input and output, netio functions may use internal buffers of configurable sizes (recv-bufsize and send-bufsize, respectively, expressed in bytes). Some applications may use unbuffered input or output. The setting of buffer size is not allowed in these cases. Both buffer sizes default to 16KB.

The netio functions use recv-timeout when waiting for client or server responses. It is used when the proxy is awating some input from a client or server. Its use is protocol-dependent. On the other hand, send-timeout is used when data has been sent to a peer (client or server) and the proxy is waiting for the acknowledgment of that operation. Both values are expressed in seconds and default to 120 seconds.

When closing a TCP connection, netio waits for the peer (usually the client or the server) to close its half of the connection. If the peer does not close the connection until close-timeout expires, the proxy terminates the connection by TCP reset. This prevents TCP sockets from getting stuck in the FIN_WAIT_2 state for a long time. The default value is likely to be suitable for most situations. It should be increased only if it is really needed, because waiting for the close blocks a proxy process. If set to zero, the connection will be terminated by reset whenever the proxy closes the connection earlier than the peer.

If full logging is set (see logging(7) for more details), the netio functions also log all the data going through. This may lead to very extensive logging and have significant impact on firewall performance and even on its overall behavior. It is therefore possible to limit the number of data octets per block that are logged in the full logging mode. This is done through the configurable parameter log-limit, which is set to 80 (expressed in bytes) by default.

All attributes of an application socket are collected in one configuration section, which is called sock-opt. Proxies may use several instances of that structure, typically one for each socket.

For example, tcp-proxy uses two instances of sock-opt:

On the other hand, ftp-proxy has four such sections:

Examples

The following is a sample excerpt from tcp-proxy configuration:

client-conn {
    recv-timeout 60;
    recv-bufsize 32768;
    send-timeout 60;
    send-bufsize 32768;
    log-limit 64;
}
server-conn {
    conn-timeout 120;
    recv-timeout 300;
    recv-bufsize 32768;
    send-timeout 600;
    send-bufsize 32768;
    log-limit 64;
}

The client connection timeouts are set to lower values, because we know that clients are on our local network. The connection timeout is relevant only for server connections, as client connections are always initiated by clients. We set the same buffer sizes of 32KB.

The following is a sample excerpt from ftp-proxy configuration:

client-ctrl {
    recv-timeout 30;
    recv-bufsize 2048;
    send-timeout 60;
    send-bufsize 2048;
    log-limit 2048;
}
server-ctrl {
    conn-timeout 120;
    recv-timeout 300;
    recv-bufsize 2048;
    send-timeout 600;
    send-bufsize 2048;
    log-limit 2048;
}
client-data {
    conn-timeout 15;
    recv-timeout 60;
    recv-bufsize 32768;
    send-timeout 60;
    send-bufsize 32768;
    log-limit 64;
}
server-data {
    conn-timeout 120;
    recv-timeout 300;
    recv-bufsize 32768;
    send-timeout 600;
    send-bufsize 32768;
    log-limit 64;
}

Both control and data connections with clients have their timeout values lower. Both client and server control connections have much lower buffer sizes, as there is supposed to be much lower data flow in control connections than within data connections. The client control connection timeout is irrelevant, as these connections are always issued by clients. However, client data connection may be initiated both by the firewall and by clients, depending on the FTP data mode (either PORT, or PASSIVE). Also, we may want to have more data logged in control connections (which are, in fact, commands) and less data in data connections.

See Also

netio(5), configuration(7), logging(7)

Authors