Antecedentes sobre o tempo limite / temporizadores de ASA:
A conexão global tempo limite é o temporizador ocioso do circuito virtual TCP (sessão) e o padrão é 60 minutos. O tempo limite udp global é para buracos UDP e o padrão é 2 minutos. O tempo limite global xlate é para limpar as traduções que perduram após uma conexão expirou. O tempo limite conn (TCP) tem precedência sobre o tempo limite xlate . O próximo parágrafo explica ainda mais a relação entre temporizadores conn e xlate.
Se um conn for destruído com sucesso através do desdobramento TCP, o conn e o xlate vão com ele (se o xlate dinâmico, o NAT estático e o xate de PAT estático nunca forem removidos). Se um conn expirar, então o cronômetro xlate é levado em consideração. Se o xlate expirar primeiro (você define o valor real), ele não interromperá a conexão até que o tempo limite seja atingido.
O ASA tem vários métodos para lidar com os variados tempos limite. Conn é aquele em que a configuração global pode ser substituída com base no mapa de classe - isso deve ser preferível ao aumentar a configuração global, se possível.
A outra característica interessante que o ASA possui está morta detecção de conexão - DCD. O DCD permite que você mantenha seu tempo limite de conexão [global] em 60 minutos (o padrão) e quando 60 minutos são alcançados - o ASA man-in-the-middle falsifica ACKs de dados nulos para cada ponto final como o outro ponto final. Dados nulos funcionam para evitar que os números de sequência sejam incrementados. Se ambos os lados responderem, o temporizador de inatividade da conexão será redefinido como 0 e começará novamente. Se um dos lados não responder após um determinado número de tentativas (configurável) em um determinado período, o conn será removido e o cronômetro xlate ganhará relevância conforme descrito acima.
Eu recomendaria configurar um mapa de classe e adicioná-lo à sua política que habilita o DCD. Você pode usar uma ACL ou uma porta (outras também estão disponíveis). Usar a porta é rápido, fácil e funcionará bem se você tiver certeza de que o TCP / 5633 é o local onde o problema fica ..
Eu usei a global_policy abaixo, mas fique à vontade para ajustar conforme necessário.
class-map BE-CORBA_class
description Backup Exec CORBA Traffic Class
match port tcp eq 5633
policy-map global_policy
class BE-CORBA_class
-->::Choose one below::<--
set connection timeout idle 1:00:00 dcd --> for 8.2(2) and up
set connection timeout tcp 1:00:00 dcd --> for prior to 8.2(2)
service-policy global_policy global
@Comment
De acordo com o guia de referência - "Um pacote pode corresponder a apenas um mapa de classe no mapa de políticas para cada tipo de recurso ."
A frase-chave está em negrito. Um pacote que cruza uma interface pode corresponder a várias classes dentro de um mapa de políticas, mas apenas se essas classes usarem "recursos" diferentes. Se você rolar para cima apenas um pouco no link acima mencionado, você verá os vários recursos listados. Essa página inteira é uma mina de ouro para petiscos do MPF.
Como você mencionou, você tem um mapa de classe match any definido e, em seguida, é referenciado como uma classe dentro do mapa de política - se estiver executando outras alterações nos limites e tempos limite de conexão TCP e UDP nessa classe de mapa de política Em seguida, os mapas de classe subsequentes que correspondem ao tráfego - se definido no mapa de políticas - não realizarão os limites de conexão TCP e UDP e as alterações de tempo limite no pacote.
Se você postar todas as ACLs, class-map , policy-map e service-policy , poderemos determinar com certeza.