OpenVPN Connection Reset: erro após atualizar a versão do cliente

O sintoma é sempre o mesmo: o OpenVPN GUI conecta, valida o certificado, e trava em loop — Connection reset, restarting a cada poucos segundos, com o intervalo de retentativa crescendo (1s, 2s, 4s… até 300s), sem nunca estabilizar.

Na maioria dos casos, isso começa logo depois que a versão do cliente OpenVPN foi atualizada — não antes. O Windows em si não é a causa: é a nova versão do próprio programa OpenVPN que muda de comportamento.

O log que expõe o problema

Um trecho típico desse cenário:

VERIFY OK: depth=0, CN=Server
Connection reset, restarting [-1]
Closing DCO interface
SIGUSR1[soft,connection-reset] received, process restarting
MANAGEMENT: >STATE:...,RECONNECTING,connection-reset,,,,,
Restart pause, 1 second(s)

O TLS completa a validação do certificado (VERIFY OK). O problema não é autenticação, não é firewall bloqueando a porta, e não é senha incorreta. A falha acontece depois — na abertura do canal de dados — e junto dela aparece uma linha que costuma passar despercebida:

Closing DCO interface

Depois de várias tentativas curtas, o padrão muda para:

TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
Fatal TLS error (check_tls_errors_co), restarting

Esse segundo erro engana muita gente a investigar rede (firewall, proxy, operadora) — mas o handshake TLS já tinha funcionado nas tentativas anteriores do mesmo log. Se fosse bloqueio de rede, o certificado nunca chegaria a validar.

Por que isso só começa depois de atualizar a versão do cliente

DCO (Data Channel Offload)

A partir da série 2.6.x, o cliente OpenVPN para Windows passou a habilitar por padrão o DCO — Data Channel Offload, um driver em modo kernel que acelera o tráfego do túnel movendo o processamento do canal de dados para dentro do driver de rede, em vez de tratá-lo em espaço de usuário.

Em servidores modernos isso é transparente. Mas contra um servidor OpenVPN legado — como o serviço embutido no MikroTik RouterOS, configurado anos atrás com parâmetros antigos — o DCO frequentemente não fecha a negociação do canal de dados corretamente, e o cliente entra no ciclo de reset.

Antes da atualização, o cliente rodava uma versão sem DCO (ex: 2.5.8) e conectava sem esse conflito. Depois de atualizar para uma versão 2.6.x ou superior — instalando manualmente o novo pacote do OpenVPN GUI, o que às vezes acontece junto de uma atualização geral do Windows, mas não é causado por ela — o novo binário já vem com DCO ativo, e a mesma configuração .ovpn que sempre funcionou passa a falhar.

O aviso de cifra que ninguém lê

No topo do log, antes de qualquer tentativa de conexão, aparece:

DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.

Isso não é um erro fatal — é só um aviso — mas revela a segunda metade do problema. Perfis .ovpn antigos definem a cifra assim:

cipher AES-256-CBC
auth SHA1

Só isso, sem data-ciphers nem ncp-ciphers. Versões recentes do OpenVPN ignoram --cipher isolado para fins de negociação (NCP — Negotiable Crypto Parameters) e esperam a lista explícita em --data-ciphers. Sem ela, o cliente tenta negociar cifras modernas (GCM/CHACHA20) que o servidor legado, configurado só para CBC, não entende — mais um ponto de atrito somado ao DCO.

Diagnóstico: como confirmar que é esse o caso

Antes de aplicar qualquer correção, confirme os três sinais no log do cliente (Painel de Controle do OpenVPN GUI → visualizar log, ou o arquivo em %USERPROFILE%\OpenVPN\log\):

1. VERIFY OK: depth=0 aparece antes da falha — descarta problema de certificado ou firewall bloqueando a porta.
2. Closing DCO interface aparece em toda tentativa de reconexão.
3. O aviso DEPRECATED OPTION: --cipher set to... aparece na inicialização do processo.

Se os três estiverem presentes, o diagnóstico está confirmado: conflito entre DCO ativo no cliente novo e servidor com negociação de cifra legada. Não é necessário testar conectividade de rede (Test-NetConnection, tracert) — o próprio handshake TLS bem-sucedido já descarta bloqueio de camada de rede.

⚠️ Atenção: não desative o antivírus nem libere portas de firewall como tentativa de correção nesse cenário. O sintoma é idêntico ao de inspeção SSL de alguns antivírus corporativos (o módulo de scan de conexão criptografada de alguns produtos gera o mesmo Connection reset depois do VERIFY OK). Confirme os três sinais do log antes de mexer em segurança do endpoint — driver de rede residual de antivírus recém-removido também pode gerar sintoma parecido sem relação nenhuma com DCO.

A correção: três linhas no arquivo .ovpn

Edite o arquivo de perfil do cliente (não o MikroTik — a mudança é só no lado do cliente Windows) e adicione, logo abaixo da linha cipher:

disable-dco
data-ciphers AES-256-CBC
data-ciphers-fallback AES-256-CBC

O que cada linha resolve:

• disable-dco — desliga o driver de offload em modo kernel e volta o processamento do canal de dados para espaço de usuário, exatamente como as versões antigas (2.5.x) sempre fizeram. Elimina o Closing DCO interface do ciclo de reset.
• data-ciphers AES-256-CBC — declara explicitamente a cifra que o servidor legado aceita, no formato que o NCP moderno exige.
• data-ciphers-fallback AES-256-CBC — garante compatibilidade mesmo se a negociação NCP falhar por completo, forçando o fallback direto para a cifra legada.

Depois de salvar, feche o OpenVPN GUI completamente pelo ícone da bandeja (não só desconectar — sair do processo) antes de reconectar. O serviço em background às vezes mantém a configuração antiga em memória até um reinício limpo do processo.

Isso é a correção definitiva ou só um remendo?

É importante separar as duas coisas. disable-dco + data-ciphers resolve o sintoma no cliente, e resolve de forma estável — não é gambiarra temporária, é a configuração de compatibilidade correta para esse cenário. Mas a causa raiz continua no servidor: enquanto o serviço OpenVPN do MikroTik não for atualizado para negociar cifra moderna (NCP com AEAD), todo cliente que for atualizado no futuro vai precisar dessas mesmas três linhas de novo.

A correção estrutural — fora do escopo de um ajuste rápido de cliente — é modernizar o .ovpn gerado pelo servidor para já sair com ncp-ciphers incluindo AEAD (AES-256-GCM:AES-128-GCM:AES-256-CBC), eliminando a necessidade de forçar CBC manualmente em cada estação.

Isso não é exagero de zelo: segundo o relatório Annual Outage Analysis 2025 do Uptime Institute, citado pela Network World, problemas de configuração e gestão de mudanças respondem por 62% das causas mais comuns de interrupções relevantes em sistemas de TI — exatamente o padrão deste caso, em que uma atualização de rotina do cliente expôs uma configuração de servidor que nunca tinha sido revisada.

Perguntas frequentes

Por que o OpenVPN entra em loop de “Connection reset, restarting” só depois que atualizei a versão do cliente?
Porque a partir da série 2.6.x o cliente passou a ativar o DCO por padrão, um driver que acelera o canal de dados mas costuma falhar contra servidores OpenVPN configurados com parâmetros antigos de cifra. A versão anterior (ex: 2.5.8) não tinha DCO, por isso conectava normalmente com o mesmo arquivo .ovpn.

O disable-dco resolve para sempre ou preciso repetir isso toda vez?
Resolve de forma estável nesse cliente específico, mas não corrige o servidor. Se o MikroTik continuar sem ncp-ciphers moderno, qualquer outro computador que for atualizado no futuro vai apresentar o mesmo sintoma e vai precisar das mesmas três linhas no .ovpn dele.

Por que aparece “TLS key negotiation failed to occur within 60 seconds” se o certificado já validou?
Porque esse erro específico não é falha de autenticação — é o tempo limite de 60 segundos esgotando enquanto o cliente tenta reabrir o canal de dados repetidamente após o Connection reset. O handshake de certificado já tinha sido concluído antes; o problema é a etapa seguinte, não a validação em si.

Se a sua VPN está caindo assim e você não tem certeza se o problema está no cliente ou no servidor, fale com a gente no WhatsApp e a gente confirma antes de qualquer mudança.