Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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>


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" (
share|improve this question
What are your values for the various /proc/sys/net/ipv4/tcp_keepalive* variables? – Goyuix Oct 8 '09 at 14:15
tcp_keepalive_intvl = 75 tcp_keepalive_probes = 9 tcp_keepalive_time = 7200 – Minkus Oct 8 '09 at 15:46
What's really missing is the iptables rules themselves. Depending on how it's set up, the handling of existing connections can change. – Avery Payne Oct 8 '09 at 20:49
What do you need to know? One of the first rules on the list is: iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT and I presumed this should handle anything that has already been established. – Minkus Oct 9 '09 at 9:46

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:

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!

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.