idle tcp connection timeout

Some firewalls can be configured to send a RST when timing out the connection, but most likely that is not the default configuration for Astaro; e.g. any new traffic on the connection will be blocked until the clients restart the connection.

Are you sure the connection is idle (did you run a sniffer?)?
Some applications such as SSH can send a NOOP to keep the connection alive.

It's possible that you may also need to turn on "Use strict TCP session handling" in WebAdmin under Network Security > Firewall > Advanced.

Barry

Some firewalls can be configured to send a RST when timing out the connection, but most likely that is not the default configuration for Astaro; e.g. any new traffic on the connection will be blocked until the clients restart the connection.

Are you sure the connection is idle (did you run a sniffer?)?
Some applications such as SSH can send a NOOP to keep the connection alive.

It's possible that you may also need to turn on "Use strict TCP session handling" in WebAdmin under Network Security > Firewall > Advanced.

Barry

Bumping this topic since I am searching through the forums for configuring port timeouts to avoid connection errors with my hospital lab.  Their machines have a NAT Ip connected to a terminal server (private ip) that routes connection to datacenter over MPLS connection.

Based on the displayed nats below, I need to make sure the UTM doesn't let these ports timeout, 

10.255.1.99 is a server in the datacenter -> 10.141.12.X is xyplex terminal server > 172.16.176.X is the lab interface machine.

tcp 172.16.176.46:2100 10.141.12.6:2100 10.255.1.99:4203 10.255.1.99:4203
tcp 172.16.176.46:2200 10.141.12.6:2200 10.255.1.99:4369 10.255.1.99:4369
tcp 172.16.176.46:2800 10.141.12.6:2800 10.255.1.99:7815 10.255.1.99:7815
tcp 172.16.176.46:2900 10.141.12.6:2900 10.255.1.99:4252 10.255.1.99:4252
tcp 172.16.176.46:3200 10.141.12.6:3200 10.255.1.99:4312 10.255.1.99:4312
--- 172.16.176.46 10.141.12.6 --- ---
tcp 172.16.176.47:3200 10.141.12.7:3200 10.255.1.99:4342 10.255.1.99:4342
tcp 172.16.176.47:3300 10.141.12.7:3300 10.255.1.99:4285 10.255.1.99:4285
tcp 172.16.176.47:3700 10.141.12.7:3700 10.255.1.72:3089 10.255.1.72:3089
Pro Inside global Inside local Outside local Outside global
--- 172.16.176.47 10.141.12.7 --- ---
--- 172.16.176.48 10.141.12.8 --- ---
tcp 172.16.176.49:9804 10.141.12.9:9804 10.255.1.96:4780 10.255.1.96:4780
tcp 172.16.176.49:9805 10.141.12.9:9805 10.255.1.96:4793 10.255.1.96:4793
tcp 172.16.176.49:55679 10.141.12.9:55679 10.255.1.96:9806 10.255.1.96:9806
--- 172.16.176.49 10.141.12.9 --- ---

Meditech controls when to open and close these ports, if the firewall closes the ports the lab goes down and I have to put the old firewall back on.

Now for this problem is why I quit trying to use the XG 310 and installed the UTM9 over it.

With the XG in a transparent bridge mode, I had to overcome asymmetric routing for the lab interface to stay up.

With the XG in gateway mode with same settings, the lab interface would fail.

Would using strict TCP session handling address this issue?

As root at the command line, you can see the available settings.

 # cc get packetfilter timeouts
{
          'ip_conntrack_generic_timeout' => 600,
          'ip_conntrack_icmp_timeout' => 30,
          'ip_conntrack_tcp_timeout_close' => 10,
          'ip_conntrack_tcp_timeout_close_wait' => 60,
          'ip_conntrack_tcp_timeout_established' => 86400,
          'ip_conntrack_tcp_timeout_fin_wait' => 120,
          'ip_conntrack_tcp_timeout_last_ack' => 30,
          'ip_conntrack_tcp_timeout_max_retrans' => 300,
          'ip_conntrack_tcp_timeout_syn_recv' => 60,
          'ip_conntrack_tcp_timeout_syn_sent' => 120,
          'ip_conntrack_tcp_timeout_time_wait' => 120,
          'ip_conntrack_udp_timeout' => 30,
          'ip_conntrack_udp_timeout_stream' => 180
        }

Which one do you want to change?