Troubleshooting de Instabilidade em VPN Remote Access

Cisco Secure Client em Cisco Secure Firewall (FTD/FMC)

Este artigo nasce de um caso real identificado em um cliente, no qual estive diretamente envolvido, que apresentava instabilidade e lentidão na VPN Remote Access, tanto logo após o estabelecimento da conexão quanto durante o uso da sessão. O cenário envolvia Cisco Secure Client (CSC) operando sobre Cisco Secure Firewall Threat Defense (FTD), com gerenciamento via Cisco Secure Firewall Management Center (FMC), todos executando a versão 7.6.x, que, na data deste artigo, é a versão estável e recomendada pela Cisco.

A ideia aqui não é trazer teoria, mas documentar duas correções simples e extremamente eficazes, que resolveram o problema de forma definitiva.

Se este relato ajudar alguém a economizar tempo em um tshoot parecido, o objetivo já foi cumprido.

Sintomas Observados

Os usuários relataram instabilidade e degradação de desempenho logo após o estabelecimento da VPN, com os seguintes comportamentos:

Conexão estabelecida com sucesso, seguida de queda após poucos segundos
Loop de reconexão automática do Cisco Secure Client
Quedas de sessão sem solicitação de nova autenticação
Lentidão perceptível no início da sessão
Em alguns casos, a VPN estabilizava apenas após duas ou três tentativas de conexão
Lentidão nos acessos a recursos internos
Lentidão na navegação e em acessos externos através da VPN

Esses sintomas reforçavam a falsa percepção de problema na conexão do usuário, quando, na realidade, a causa estava relacionada a parâmetros de configuração no próprio firewall.

Análise Inicial

Durante a análise dos logs no FMC e na CLI do FTD, foi possível observar:

Sessões sendo estabelecidas corretamente
Quebras logo após a troca inicial de pacotes
Tentativas de renegociação de transporte
Reestabelecimento automático da conexão pelo cliente

A partir desse comportamento, duas configurações chamaram atenção:

MTU configurado acima do ideal para o cenário
Uso de DTLS em um ambiente com características que não favoreciam esse protocolo

Tudo indicava um problema no transporte, não na autenticação. Em cenários como esse, alguns fatores costumam estar envolvidos:

Fragmentação de pacotes
MTU inadequado
Tráfego UDP sendo filtrado ou degradado no caminho
CGNAT ou firewalls intermediários
Uso de DTLS em redes restritivas

A partir disso, duas abordagens foram testadas, ambas válidas e amplamente utilizadas em ambientes reais.

Correção #1 – Ajuste do MTU na Group Policy

O primeiro ajuste realizado foi a redução do MTU na Group Policy da VPN, com o objetivo de evitar fragmentação excessiva e perdas de pacote logo após a conexão.

Procedimento

No FMC, acesse:
Objects > Object Management > VPN > Group Policy
Selecione a Group Policy associada aos usuários da VPN (nosso exemplo: GRP-POLICY-VPN-USERS-1) e clique em Edit

Já dentro da aba da Group Policy, localize a configuração de MTU
Ajuste o valor para o novo MTU definido para o ambiente. Neste cenário, foi utilizado o valor 1300 Bytes
Salve a alteração e faça Deploy

Esse ajuste reduziu significativamente as quedas imediatas após a conexão, especialmente em usuários com links mais restritivos. No entanto, em alguns cenários, o problema ainda reaparecia.

Correção #2 – Desativação do DTLS

Mesmo após o ajuste do MTU, ainda foram observados alguns casos pontuais de reconexão e lentidão. A segunda correção envolveu a desativação do DTLS, forçando o uso exclusivo de TLS sobre TCP.

Em determinados cenários, especialmente com firewalls intermediários, NATs agressivos ou links instáveis, o DTLS pode introduzir mais problemas do que benefícios.

Por que o DTLS pode causar problemas?

O DTLS utiliza UDP, o que traz melhor performance, mas também alguns desafios:

Firewalls intermediários podem bloquear ou limitar UDP
CGNAT trata mal sessões UDP longas
Redes públicas e ISPs costumam priorizar TCP 443
ICMP frequentemente é bloqueado, afetando MTU

Resultado: sessões que conectam, mas não se mantêm estáveis.

O que muda ao desativar o DTLS

Com o DTLS desativado:

O CSC passa a usar exclusivamente SSL/TLS (TCP 443)
Não ocorre migração automática para UDP
A conexão se torna muito mais previsível
Há um pequeno impacto de performance, mas grande ganho de estabilidade

Em ambientes corporativos, estável quase sempre vence rápido.

Procedimento para desativar o DTLS no FMC

No FMC, acesse:
Devices > Remote Access
Selecione a política de VPN Remote Access

Acesse a aba Access Interfaces
Localize a interface habilitada para a VPN e clique em Edit

Na aba de configuração da interface, desmarque a opção Enable DTLS
Clique em OK

Por fim, clique em Save para salvar a configuração e, em seguida, realize o Deploy para que o ajuste seja efetivamente aplicado no firewall

Após essa alteração, a instabilidade foi completamente eliminada no ambiente.

Novas conexões CSC utilizam apenas TCP
O comportamento de “conecta e cai” desaparece
Houve uma melhora significativa de performance, tanto na inicialização da sessão quanto durante o uso contínuo da VPN

Qual abordagem escolher?

Estratégia	Quando usar
Ajuste de MTU (1300)	Ambientes controlados, mantendo DTLS
Desativar DTLS	Usuários remotos, redes imprevisíveis, CGNAT
Ambas	Ambientes grandes e heterogêneos

Na prática, as duas soluções podem coexistir, dependendo do perfil de acesso.