Il numero massimo di connessioni che il kernel riesce a gestire è stabilito da /proc/sys/net/ipv4/ip_conntrack_max, lo stato attuale delle connessioni riconosciute è invece in /proc/net/ip_conntrack.

Per stroncare una connessione in essere?

Vedere questo articolo sul Connection tracking prelevato qui.

A web server is reachable from the internet onto a local host (192.168.1.5) via a DNAT rule, local hosts want to use the public address (130.151.100.69) to reach the d-natted server. Traffic will be masqueraded by the firewall with its address (192.168.1.254) on the local LAN (eth0):

In /etc/shorewall/interfaces:

#ZONE    INTERFACE    BROADCAST    OPTIONS
loc      eth0         detect       routeback

In /etc/shorewall/masq:

#INTERFACE        SUBNET  ADDRESS        PROTO  PORT(S)
eth0:192.168.1.5  eth0    192.168.1.254  tcp    www

In /etc/shorewall/rules:

#ACTION  SOURCE  DEST             PROTO  DEST PORT  SOURCE  ORIGINAL
#                                                   PORT    DEST.
DNAT     loc     loc:192.168.1.5  tcp    www        -       130.151.100.69

How the various tables are traversed? This is an handy schema found here:

There is a problem starting Shorewall on a diskless host which mounts its root filesystem via NFS; the standard behaviour of Shorewall on start, is to set a DROP default policy for INPUT and OUTPUT chains before enforcing other rules. In this way the NFS mount gets blocked while Shorewall tries to acquire a lockfile on the disk and the entire host is screwed. The error message is:

lockfile: Sorry, giving up on "/var/lock/shorewall"

There is a non-documented feature called CRITICALHOSTS, this is a list of hosts that requires to never be blocked. Just put into /etc/shorewall/shorewall.conf someting like:

CRITICALHOSTS="eth0:172.21.10.1 eth0:172.21.10.254"

WARNING the interface name is required, otherwise the iptable rules are syntactically correct, but ineffective. May be this is a bug of Shorewall 4.0.8.