Falha na conexão VPN RRAS L2TP/IPsec (Erro 789) — como validar L2TP, PSK e NAT-T?

Question

Falha na conexão VPN RRAS L2TP/IPsec (Erro 789) — como validar L2TP, PSK e NAT-T?

Pedro Costa 60

Pessoal, estou enfrentando um problema com os usuários remotos tentando se conectar à nossa VPN RRAS via L2TP/IPsec. A conexão falha imediatamente e retorna o Erro 789 (The L2TP connection attempt failed because the security layer encountered a processing error...).

Preciso validar e isolar a causa raiz nas máquinas clientes e no servidor. Qual é o checklist exato para checar:

Dependências do serviço IPsec: Quais serviços do Windows além do IKEEXT e PolicyAgent precisam estar rodando e como checar os logs de auditoria de IPsec via Event Viewer?
Pre-Shared Key (PSK): Existe algum cmdlet em PowerShell ou log do Oakley/IKE para confirmar se o erro é exatamente mismatch de chave pré-compartilhada antes da fase 2 da negociação?
Configurações de NAT-Traversal (NAT-T): Sei que quando o cliente ou o servidor RRAS estão atrás de um roteador/firewall NAT, o Windows precisa da chave de registro AssumeUDPEncapsulationContextOnSendRule. Qual é o valor correto (1 ou 2) para quando ambos estão atrás de NAT e é necessário reiniciar o serviço PolicyAgent logo após?

Se alguém tiver os comandos em PowerShell/CMD (netsh, Get-Service, etc.) para automatizar essa validação nos clientes, agradeço demais!

0 comentários

Resposta aceita pelo autor da pergunta

0 respostas adicionais

Sua resposta

Answer 1

Olá,

o erro 789 em conexões L2TP/IPsec geralmente indica falha na fase inicial da negociação IPsec. Para validar corretamente, você precisa confirmar três pontos principais: serviços, chave pré‑compartilhada e NAT‑Traversal.

No lado dos serviços, além de IKEEXT e IPsec PolicyAgent, o RemoteAccess e o RasMan devem estar ativos. Você pode verificar com Get-Service IKEEXT, PolicyAgent, RemoteAccess, RasMan | Format-Table Name, Status. Para auditoria, abra o Event Viewer em Applications and Services Logs > Microsoft > Windows > IPsec > Operational e também em Security com a política de auditoria de logon habilitada. Esses logs mostram falhas de SA (Security Association) e erros de chave.

Quanto ao PSK, não existe cmdlet direto para exibir a chave, mas você pode confirmar mismatch analisando os logs Oakley/IKE em Event Viewer > Security > Audit Failure e em %SystemRoot%\debug\oakley.log (se habilitado via netsh trace start scenario=IKE). Se o erro ocorre antes da fase 2, quase sempre é PSK incorreta.

Para NAT‑Traversal, o registro crítico é HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent\AssumeUDPEncapsulationContextOnSendRule. O valor deve ser 2 quando ambos cliente e servidor estão atrás de NAT. Se apenas um lado está atrás de NAT, use 1. Após alterar, reinicie o serviço PolicyAgent com Restart-Service PolicyAgent.

No cliente, você pode automatizar a validação com:

Código

Get-Service IKEEXT, PolicyAgent | Format-Table Name, Status
netsh ipsec dynamic show all

e para NAT‑T:

Código

reg query HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent /v AssumeUDPEncapsulationContextOnSendRule

Assim você confirma se os serviços estão ativos, se o registro está correto e se os logs apontam para mismatch de PSK.

Domic Vo.