idle tcp connection timeout

Hi
   I have configured ip_conntrack_tcp_timeout_established" =900 sec
still if connection remains idle for more than 900 sec then also not dropped by firewall
My configuration are
masquerading rule between client and server
client in internal network and server is in public network
in packet filter Allow all packet using any service from internal to internet
Thanks

Hi All
Can I know how astaro internally drops idle tcp connection.Does it sends any packet when drops TCP connection

Thanks

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

Thanks BarryG.Actually I am using astaro to test my client server based application.I wanted to know one more thing that when my clint is in internal network and server is in public network,and masquerading rule Internal(network) ------>external(address) is configured.If am sending data from server to client then it is taking some more time than data sending from server to client when there is no firewall.But it is fine in case of data transfer from client to server having above configuration.Is astaro makes some dealay is above scenario?

1. Are you using the http proxy? (aka content filter aka web security) --there can be some delays added, especially if doing anti-virus scanning. 
take a look at the web log to see if some of the packets are getting blocked.

2. the IPS and some other features can cause slowdowns. Check your hardware graphs, including CPU and RAM utilization.
Run 'top' during a data transfer and see if there is high CPU utilization.
disable the IPS and application detection, and see if there's any difference

3. how fast is your internet connection?

4. what is your CPU and RAM configuration?

5. take a look at the IPS log to see if some of the packets are getting blocked.

6. what kind of connection are you using (PPPoE or Ethernet)? 
Are you using a VPN?
maybe your MTU is wrong.

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?