Perda de Comunicação entre FTD e FMC

Ajuste de Timeout do sftunnel em Ambientes Lentos ou Congestionados

Durante operações em ambientes de produção, alguns problemas não aparecem de forma direta ou óbvia. Eles surgem de maneira intermitente, desaparecem sozinhos, voltam sem um padrão claro e, muitas vezes, acabam sendo tratados como “instabilidade momentânea da rede”.

Este artigo nasce exatamente de um cenário real que enfrentei recentemente, no qual houve perda de comunicação entre um Cisco Secure Firewall Threat Defense (FTD) e o Cisco Secure Firewall Management Center (FMC). Após análise conjunta com o TAC da Cisco, foi identificado que o comportamento estava relacionado ao sftunnel e aos parâmetros de timeout em redes mais lentas ou congestionadas.

Contexto do Problema

O ambiente apresentava momentos de perda de comunicação entre o FTD e o FMC. O comportamento era intermitente: em alguns momentos tudo funcionava normalmente, e em outros o FMC passava a reportar falhas de comunicação com o FTD, sem alterações aparentes de configuração.

Sintomas Observados

Durante a análise dos logs, o seguinte erro aparecia repetidamente no arquivo messages.log:

*STALE CONNECTION DETECTED: Delay for connection check reply*

Os principais sintomas percebidos no ambiente foram:

  • Falha no Deploy
  • Falha intermitente em backups simultâneos
  • Perda temporária de comunicação entre FTD e FMC
  • Reconexões frequentes do túnel de gerenciamento
  • Instabilidade maior em períodos de carga elevada ou tráfego intenso

Análise da Causa

Segundo a Cisco (Bug CSCwk06689), esse comportamento ocorre quando o sftunnel passa a classificar conexões ativas como “STALE” em ambientes onde há:

  • Latência elevada
  • Perda de pacotes
  • Rede lenta ou instável
  • Equipamentos sob carga elevada

Em redes mais lentas, o atraso na resposta dos checks de conectividade pode ultrapassar o limite padrão configurado, levando o sftunnel a assumir, de forma incorreta, que a conexão não está mais ativa.

Recomendação do TAC (Workaround)

Como mitigação do problema, o TAC recomendou o ajuste do parâmetro responsável por controlar a tolerância a atrasos nos checks de conexão do sftunnel.

Ajuste de Configuração

Em ambos os equipamentos (FMC e FTD), no arquivo:

/etc/sf/sftunnel.conf

Localize o parâmetro:

MAX_CONN_CHECK_REPLIES_MISSED 3;

E altere para:

MAX_CONN_CHECK_REPLIES_MISSED 10;

Esse ajuste aumenta a tolerância do sftunnel a atrasos nas respostas, evitando que conexões válidas sejam marcadas como inativas de forma prematura.

Caso o problema persista, a Cisco orienta que esse valor pode ser aumentado gradualmente, até um máximo de 45, sempre avaliando o comportamento do ambiente.

Aplicando a Alteração

Após salvar a modificação no arquivo de configuração, é obrigatório reiniciar o serviço do sftunnel para que o ajuste entre em vigor.

Execute o comando:

pmtool restartbyid sftunnel

⚠️ Importante:
A reinicialização do sftunnel causa uma interrupção temporária na comunicação entre o FTD e o FMC. Durante esse período, pode haver impacto momentâneo em:

  • Eventing
  • User mappings
  • Comunicação de gerenciamento

Por isso, recomenda-se realizar esse procedimento em uma janela controlada.

Conclusão 🧘‍♂️

Esse caso reforça um ponto importante: nem toda instabilidade está relacionada diretamente a falhas de link ou erro de configuração. Em ambientes mais complexos, parâmetros internos, como timeouts e tolerâncias de serviços, podem fazer toda a diferença.

O sftunnel é um componente crítico na comunicação entre o FTD e o FMC, e em redes com maior latência ou variabilidade, ajustes finos podem ser necessários para garantir estabilidade operacional.

Documentar esse tipo de experiência prática ajuda não só a resolver problemas futuros mais rapidamente, mas também a entender melhor como a plataforma se comporta em cenários reais de produção.

Se este relato economizar algumas horas de troubleshooting em um cenário parecido, o objetivo do artigo já foi alcançado.

Deixe um comentário