Who rated this post

The difference in counts is due to how connections are reported and to some degree output formatting.

fw tab -u -t connections -f doesn't really track connections as a singular entity; it tracks flows of packets.  For non-NATted connections there will be two lines shown for every "connection", a c2s (client to server) flow from the original initiator to the responder, and a s2c (server to client) return flow.  For connections that are NATted, there will be 4 total flow lines in the output: c2s pre-NAT, c2s post-NAT, s2c pre-NAT, and s2c post-NAT.  This is why the fw tab command shows 4X the true number of connections displayed by fw ctl pstat.

fw ctl conntab shows each connection and all its associated flows on just one line, however it does place a newline after each reported connection.  So if you are doing a straight line count this command will show 2X the amount reported by fw ctl pstat.

All of the above counts are tracked on the Firewall Worker/Instance cores.

On the other hand fw ctl multik gconn is showing what the Dynamic Dispatcher is doing on the SND cores, namely keeping track of which connections and their associated flows are assigned to which Firewall Worker/Instance.  It operates similarly to the fw tab command and will show 4 lines/flows for each NATted connection.  I believe the slightly elevated count for fw ctl multik gconn  over fw tab is due to the fact that a connection's worker core assignment will stick around for a bit in the Global Connections table, even after the connection has been closed and removed from the table on the Firewall Workers.  I assume this helps ensure that if a wayward late packet for what appears to be a closed connection happens to show up, it will still be sent to the original worker core who may "resurrect" it via something like this: sk24960: "Smart Connection Reuse" feature modifies some SYN packets.