Como configurar o firewall do Linux para permitir que o Exchange Server ActiveSync Direct Push funcione sem avisos

Question

Estou enfrentando eventos de aviso do EventID 3033 'Server ActiveSync' em nosso servidor Exchange 2003 SP2, descritos em KB905013 (veja abaixo), aparentemente devido a tempos limite de firewall.

O servidor Exchange está protegido por um firewall baseado no iptables do Red Hat Enterprise Linux 5.4, mas não sei quais configurações devem ser verificadas para garantir que o tempo limite de HTTP (S) seja definido em pelo menos 15 minutos, conforme descrito no artigo .

Alguém pode me dizer onde estão as configurações que afetam os tempos limite do firewall do iptables no Linux e como posso alterá-los?

Erro no registro de eventos:

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

Tendo feito algumas investigações, tanto quanto eu posso ver o tempo limite padrão do netfilter do Linux para conexões TCP 'estabelecidas' ao usar o módulo 'state' para permitir conexões ESTABLISHED é de 5 dias, muito acima dos 15 minutos recomendados pela Microsoft:

link

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.

Por isso, vou investigar outras opções, pois pode haver outro firewall no caminho causando o tempo limite.

Obrigado por aqueles que ajudaram mesmo assim!