Huge different between concurrent connections in dashboard and ssh shell

Hi, Truong, and welcome to the UTM Community!

I wonder if this isn't just a broken PostgreSQL data base.  The following command will delete the data in Reporting and graphs, but will not affect your log files:

/etc/init.d/postgresql92 rebuild

Did that fix the problem?  If not, does this mis-measurement have any effect on your use of the UTM?

Cheers - Bob

Hi Bob,

Thanks very very much for your answer and your contribution to our community. I admire that.

As I replied, this is right when compared with nf_contrack. I fixed this by decreasing all timeout parameters by half:

echo 5 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
echo 86400 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
echo 60 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
echo 15 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_last_ack
echo 150 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_max_retrans
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_recv
echo 60 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent
echo 60 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent2
echo 60 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait

Thanks again, Bob!

Truong, I don't believe that these changes will survive a reboot.  You might want to use the following commands suggested by da_merlin to make persistent changes to packetfilter timeouts.

The first one will show you what's in the configuration database that you manipulate with WebAdmin.  The second is an example of making changes to the configuration database.

cc get packetfilter timeouts

cc set packetfilter timeouts ip_conntrack_tcp_timeout_close 5

Cheers - Bob