How to configure Linux firewall to allow Exchange Server ActiveSync Direct Push to work without warnings

Question

I am experiencing EventID 3033 'Server ActiveSync' warning events on our Exchange 2003 SP2 server described in KB905013 (see below), apparently due to firewall timeouts.

The Exchange server is behind a Red Hat Enterprise Linux 5.4 iptables based firewall, but I don't know what settings to check to make sure that the HTTP(S) timeout is set to at least 15 minutes as described in the article.

Can anyone tell me where the settings are that affect iptables firewall timeouts in Linux and how I can change them?

Event log error follows:

Event Type: Warning
Event Source:     Server ActiveSync
Event Category:   None
Event ID:   3033
Date:       08/10/2009
Time:       10:42:35
User:       <REMOVED>
Computer:   <REMOVED>

Description:

The average of the most recent [200] heartbeat intervals used by clients is less than or equal to [540].  Make sure that your firewall configuration is set to work correctly with Exchange ActiveSync and direct push technology. Specifically, make sure that your firewall is configured so that requests to Exchange ActiveSync do not expire before they have the opportunity to be processed.  For more information about how to configure firewall settings when using Exchange ActiveSync, see Microsoft Knowledge Base article 905013, "Enterprise Firewall Configuration for Exchange ActiveSync Direct Push Technology" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905013).

Answer 1

Having done some investigation, as far as I can see the default Linux netfilter timeout for 'established' TCP connections when using the 'state' module to allow ESTABLISHED connections through is 5 days, way above the 15 minutes recommended by Microsoft:

http://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/netfilterreference.html

3.7.8. ip_ct_tcp_timeout_established The ip_ct_tcp_timeout_established variable tells us the default timeout value for tracked connections in the ESTABLISHED state. All connections that has finished the initial 3-way handshake, and that has not seen any kind of FIN packets are considered as ESTABLISHED. This is in other words more or less the default state for a TCP connection.

Since we never want a connection to be lost on either side of the netfilter firewall, this timeout is set extremely high so we do not accidentally erase entries that are still used. Per default, the ip_ct_tcp_timeout_established variable is set to 432000 seconds, or 5 days.

I am therefore going to investigate other options as there may be another firewall in the way causing the timeouts.

Thanks for those who helped anyway!