Quedas aleatórias de RDP em farms de Terminal Server com LoadMaster normalmente apontam para timeouts e limpeza de estado no caminho de rede. Este guia mostra como diagnosticar e corrigir as desconexões de forma prática, com ajustes em LoadMaster, GPO e firewall, além de testes controlados.
Visão geral do cenário
Você tem dois servidores Windows Server 2022 (virtualizados) atuando como Remote Desktop Session Host (RDSH), publicados por um Kemp LoadMaster em TCP/3389. Várias vezes ao dia, grupos de 3–4 usuários caem no mesmo segundo, reconectando poucos segundos depois. No Event Viewer (log TerminalServices-LocalSessionManager), as sessões apresentam Reason Codes:
2147942521 (0x80070079)– Semaphore timeout period has expired (timeout de rede).2147942464 (0x80070040)– The specified network name is no longer available (conexão de rede perdida).
Esses códigos indicam erro de rede/transporte e, na prática, quase sempre se relacionam a timeouts de sessão ociosa ou flaps de verificação de saúde em algum ponto do caminho: balanceador, firewall/NAT ou roteador.
O que os códigos significam no contexto de RDP
| Reason Code | Mensagem | Interpretação prática | O que procurar |
|---|---|---|---|
0x80070079 | Semaphore timeout period has expired | Timeout de transporte; falta de resposta em janela de tempo. | Conexões “silenciosas” encerradas por LB/NGFW, perda de pacotes, assimetria UDP. |
0x80070040 | The specified network name is no longer available | Queda abrupta do caminho; estado TCP perdido. | Limpeza de sessão por timeout, RST de middlebox, health check marcando servidor down. |
Por que vários usuários caem no mesmo segundo
Vários dispositivos (Load Balancers, NGFWs) executam garbage collection em ciclos. Se o idle timeout for curto, as sessões RDP sem troca de dados recente são finalizadas em lote quando o coletor roda. O resultado típico é um “cluster” de desconexões no mesmo segundo, seguido de reconexão automática do cliente RDP.
Principais causas prováveis
Timeout de sessão no LoadMaster ou no firewall/NAT
O RDP pode permanecer por longos períodos sem tráfego significativo. Idles curtos (por ex., 5–15 min) em LBs/NGFWs levam a quedas periódicas e sincronizadas. Alvos clássicos: Idle Connection Timeout do Virtual Service (LoadMaster) e TCP Session Timeout do firewall/NAT.
Uso de transporte UDP do RDP sem suporte consistente no caminho
RDP 8+ usa UDP/3389 para melhorar latência e vídeo. Se o balanceador ou o firewall tratarem TCP e UDP de forma distinta (sem a mesma persistência/afinidade, NAT assimétrico, bloqueio intermitente), o cliente alterna para TCP após falhas, causando “quedas e retomadas”.
Oscilação de health check no LoadMaster
Se a verificação de saúde estiver agressiva (intervalo curto, timeout pequeno) ou verificar algo além de TCP Connect, o servidor pode ser marcado down temporariamente. Conexões ativas são derrubadas se não houver connection draining.
Interferência de DPI/IPS ou problemas de NIC/offload
Perfis de inspeção profunda (DPI/IPS) para “RDP” podem resetar fluxos em picos de carga. Em hosts virtualizados, recursos como LSO/LRO/RSS/VMQ (e drivers desatualizados) às vezes geram resets breves sob determinadas condições.
Ações imediatas recomendadas
- Aumentar timeouts no LoadMaster e no firewall/NAT:
- LoadMaster → Virtual Service do 3389: configure Idle Connection Timeout para ≥ 3600 s (1 hora). Se sua política permitir, valores de 2–4 horas reduzem o risco de quedas em pausas longas.
- Firewall/NAT à frente: alinhe TCP Session Timeout para valor igual ou maior ao do LB.
- Habilitar Keep‑Alive do RDP nos RDSH:
- GPO: Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections → Configure keep‑alive connection interval = Enabled, 60 seconds.
- (Opcional) Reforço via TCP KeepAlive do SO para 60 s.
- Executar teste forçado só‑TCP:
- GPO: …Connections → Select RDP transport protocols = Use only TCP.
- Se o problema sumir, trate UDP no balanceador/NGFW ou mantenha TCP‑apenas.
- Ajustar health check do LoadMaster:
- Use verificação simples TCP connect em 3389, aumente o intervalo e configure Connection Draining para não derrubar sessões ativas em flaps curtos.
- Realizar bypass controlado:
- Direcione um grupo de usuários a um RDSH direto (sem LB) por 1–2 dias.
- Se as quedas cessarem, foque no LB/NGFW; se persistirem, foque no host/VM/rede interna.
Parâmetros recomendados para LoadMaster e firewall
| Componente | Parâmetro | Valor recomendado | Observações |
|---|---|---|---|
| LoadMaster (Virtual Service 3389) | Idle Connection Timeout | ≥ 3600 s | Eleve conforme política de segurança e perfil de uso. |
| LoadMaster | Persistence Mode | Source IP | Evita salto de servidor no meio da sessão. |
| LoadMaster | Connection Draining | Habilitar; Grace ≥ 30 s | Protege sessões durante flaps e manutenções. |
| LoadMaster | Health Check | TCP Connect | Intervalo 10–30 s; Retry ≥ 3; Timeout 5–10 s. |
| NGFW/NAT | TCP Session Timeout (3389) | ≥ 3600 s | Igual ou maior que o valor do LB. |
| NGFW | Inspeção/DPI para RDP | Desativado para teste | Se necessário, crie exceção por origem/destino/porta. |
| NGFW | UDP 3389 | Consistência de tratamento | Mesma afinidade/persistência do TCP; evitar assimetria. |
Como habilitar Keep‑Alive no Windows Server
GPO do RDP
Computer Configuration
└── Administrative Templates
└── Windows Components
└── Remote Desktop Services
└── Remote Desktop Session Host
└── Connections
└── Configure keep-alive connection interval = Enabled, 60 seconds
Reforço de TCP KeepAlive (opcional)
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" ^
/v KeepAliveTime /t REG_DWORD /d 60000 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" ^
/v KeepAliveInterval /t REG\_DWORD /d 10000 /f Por padrão, o KeepAlive do TCP no Windows é alto (horas). As entradas acima reduzem o intervalo e ajudam a manter o fluxo “vivo” perante middleboxes.
Teste controlado só‑TCP
Para confirmar suspeita sobre UDP:
- Crie uma OU temporária contendo um grupo de usuários/pcs de teste.
- Configure a GPO Select RDP transport protocols = Use only TCP nessa OU.
- Monitore durante 24–48 h e compare taxa de quedas com o grupo controle.
Se as desconexões cessarem no grupo TCP‑apenas, reavalie o suporte a UDP no balanceador e no firewall. Alternativamente, mantenha o farm em TCP puro.
Capturas e correlação de eventos
Correlacionar horários: verifique se os Event IDs de desconexão (TerminalServices-LocalSessionManager) ocorrem em clusters no mesmo segundo. Isso é indicativo de timeout/limpeza de estado.
Captura rápida nos RDSH
# Iniciar rastreamento
netsh trace start capture=yes report=yes tracefile=C:\Temp\rdp_queda.etl
Reproduzir/aguardar a queda, então:
netsh trace stop Analise em um analisador de pacotes: observe se há RST vindos do caminho, FIN inesperados, ou silêncio até expirar o retransmit. No LoadMaster, use o packet capture embutido para ver o lado cliente e o lado servidor.
Extrair eventos focados
# PowerShell - listar últimos eventos de desconexão
Get-WinEvent -FilterHashtable @{
LogName='Microsoft-Windows-TerminalServices-LocalSessionManager/Operational';
Id=40
} | Select-Object TimeCreated, Id, Message | Sort-Object TimeCreated -Descending | Select-Object -First 50
Ajuste fino do health check no LoadMaster
- Tipo: TCP Connect em 3389. Evite checagens pesadas que possam falhar por motivos transitórios.
- Intervalo: 10–30 s, Retry: ≥ 3, Timeout: 5–10 s.
- Draining: habilite Connection Draining com grace ≥ 30 s.
- Afinidade: Persistence: Source IP para manter sessões presas ao mesmo RDSH.
Transporte UDP do RDP e caminho assimétrico
O RDP moderno utiliza UDP/3389 para mídia/entrada, mantendo TCP/3389 para controle. Em ambientes com balanceamento e inspeção, certifique-se de que:
- TCP e UDP recebam o mesmo tratamento de persistência/afinidade.
- Não exista NAT assimétrico (entrada por um caminho, saída por outro).
- Políticas de filtro/IPS não derrubem UDP de forma intermitente.
Se não puder garantir, desative UDP via GPO conforme seção anterior.
Alternativas arquiteturais recomendadas
RD Gateway: encapsula RDP em HTTPS/443 (com canal UDP/3391 quando suportado). Essa abordagem costuma ser mais resiliente a middleboxes e simplifica políticas de firewall. Combine com balanceamento e idle timeouts generosos.
RDP direto com boas práticas: se mantiver 3389 aberto, use persistência por IP, timeouts longos, e desative inspeção específica de RDP no NGFW se ela introduzir instabilidade.
Checklist de verificação
| Item | Como verificar | Critério de sucesso |
|---|---|---|
| Eventos em clusters | Logs do LSM/Operational, ID 40 na mesma marca de tempo. | Confirma hipótese de timeout em middlebox. |
| Idle Timeout do LB | Virtual Service 3389 → Timeout ≥ 3600 s. | Sem quedas durante pausas prolongadas. |
| GPO Keep‑Alive | GPO aplicada; gpresult /r. | Intervalo de 60 s efetivo. |
| Health check estável | Sem “up/down” frequente nos logs do LB. | Conectividade estável sob carga. |
| UDP consistente | Políticas idênticas para TCP/UDP; sem assimetria. | Sem quedas ao alternar mídia. |
| Firewall/NAT | TCP timeout ≥ 1h; sem DPI de RDP. | Sem resets “misteriosos”. |
Runbook sugerido
- Aumente Idle Connection Timeout no LoadMaster para ≥ 3600 s; alinhe o firewall/NAT.
- Aplique GPO de Keep‑Alive de 60 s nos RDSH.
- Habilite Connection Draining e ajuste health check para TCP Connect com retry ≥ 3.
- Desative temporariamente DPI/IPS para RDP no NGFW e valide.
- Realize teste só‑TCP com grupo de usuários; compare métricas.
- Faça bypass controlado (sem LB) por 1–2 dias; isole o culpado.
- Se persistir, faça captura simultânea no LB e no RDSH e analise RST/FIN/timeouts.
- Considere RD Gateway como padrão arquitetural.
Erros comuns que prolongam o incidente
- Tratar como problema de licenciamento RDS. Os códigos indicam rede, não CALs.
- Elevar apenas o timeout no LB e esquecer o firewall/NAT.
- Health check “exagerado” (intervalo curtíssimo, sem retry), causando flaps.
- Manter UDP habilitado sem garantir persistência e simetria de caminho.
- Ignorar drivers/firmware das NICs virtuais e do host de virtualização.
Scripts e comandos úteis
Aplicar Keep‑Alive via PowerShell
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters' `
-Name 'KeepAliveTime' -PropertyType DWord -Value 60000 -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters' \`
-Name 'KeepAliveInterval' -PropertyType DWord -Value 10000 -Force | Out-Null Auditar sessões desconectadas por minuto
$events = Get-WinEvent -FilterHashtable @{
LogName='Microsoft-Windows-TerminalServices-LocalSessionManager/Operational'; Id=40
}
$events | Group-Object { $_.TimeCreated.ToString('yyyy-MM-dd HH:mm:ss') } |
Sort-Object Name -Descending | Select-Object -First 20
Verificar offloads de NIC na VM (teste)
# Use com cautela em janelas de manutenção
Disable-NetAdapterChecksumOffload -Name "*"
Disable-NetAdapterLso -Name "*"
Disable-NetAdapterRsc -Name "*"
Quando considerar mudanças estruturais
Se, mesmo com timeouts longos e keep‑alive, ainda houver quedas causadas por inspeções intermediárias, avalie migrar a publicação para RD Gateway. O tráfego encapsulado em HTTPS evita interações problemáticas de middleboxes com a sessão RDP nativa.
Métricas de sucesso e observabilidade
- Taxa de desconexões por 100 usuários/dia → meta próxima de zero.
- Média de duração de sessão sem interrupções.
- Ocorrências de health check “down/up” por servidor no LB.
- Erros 0x80070079/0x80070040 por dia nos logs do RDSH.
Resumo prático
- Os códigos
0x80070079/0x80070040apontam para rede/timeout, não licenciamento. - Quedas simultâneas no mesmo segundo sugerem limpeza de sessão em middlebox (LB/NGFW) ou flap de health check.
- Resolva elevando idle timeouts no LoadMaster/NGFW, habilitando RDP Keep‑Alive (60 s) e realizando teste TCP‑apenas.
- Use bypass controlado para isolar a origem. Considere RD Gateway como alternativa mais resiliente.
FAQ essencial
Isso pode ser “pico de CPU/RAM” no RDSH? Em geral, não. Quedas simultâneas com reconexão rápida e razão de rede indicam o caminho de transporte, não esgotamento de recursos.
Desabilitar UDP impacta desempenho? Pode reduzir levemente a qualidade de mídia (áudio/vídeo/bi‑direcional), mas costuma ser imperceptível em cenários de escritório e é excelente para diagnóstico.
Persistência por cookie é necessária? Não para RDP. Use persistência por IP no LB.
Qual valor de timeout escolher? Para sessões interativas típicas, 1–4 horas é um bom ponto de partida, alinhado entre LB e firewall.
Modelo de comunicação pós‑mudança
Comunique aos usuários a aplicação de ajustes de estabilidade, informe janela de mudanças e peça que reportem qualquer reconexão inesperada após as alterações. Coletar horário, usuário, servidor de destino e se estava ocioso/ativo ajuda a refinar o diagnóstico.