Temos uma solução de VPN Sempre Ativo onde alguns usuários ocasionalmente têm problemas ao estabelecer o Túnel do usuário. É importante notar que isso ocorre apenas ocasionalmente e não é um problema permanente que ocorre toda hora.
O tipo de protocolo nas configurações do perfil é Automático, o que significa que VpnStrategy será SSTP, IKEv2, PPTP e depois L2TP. O Túnel do Dispositivo será estabelecido normalmente no IKEv2, mas o Túnel do Usuário falhará com o código de erro 800 após tentar todos os protocolos. (No servidor VPN, só permitimos conexões no SSTP e IKEv2)
Múltiplas tentativas resultarão na mesma falha, enquanto o Túnel do Dispositivo para o mesmo usuário estará conectado normalmente, e vários outros usuários terão Túnel do Usuário ativo normalmente. Se o tipo de protocolo for alterado para IKEv2 nas configurações do perfil, o erro não ocorre, mas precisamos usar SSTP para o Túnel do Usuário, e para isso devemos definir o tipo de protocolo como Automático nas configurações do perfil.
No log de aplicativos no cliente, o EventoID 20227 é registrado com “O usuário XYZ discou uma conexão chamada ABC que falhou. O código de erro retornado na falha é 800.”
Vi algo ontem sobre o Windows Server removendo esses tipos de conexões VPN via atualização, acho. Provavelmente não relacionado, mas menciono mesmo assim.
O SSTP ocorre sobre HTTPS na porta 443. Você verificou a condição de conectividade da web dos usuários? por exemplo, atrás de proxies, firewalls, etc.?
Você disse que isso acontece ocasionalmente - há um padrão que você consegue identificar? por exemplo, sempre acontece com pessoas em uma cadeia de hotéis específica, um fornecedor de café, residências com um ISP específico, um horário específico do dia? Isso pode ser algo tão simples quanto uma cadeia de hotéis roteando seu Wi-Fi de hóspedes através de um proxy web para bloquear sites ruins, e atrapalhar sua conexão.
Qual é a situação de conectividade IP do local remoto? Dependendo do ISP, eles podem estar usando um IPv6 e PLAT ao invés do IPv4 esperado. Mesmo que tenham IPv4, o Windows prefere IPv6, a menos que você tenha alterado especificamente.
Os túneis do dispositivo e do usuário apontam para o mesmo alvo? O alvo é estático? por exemplo, o setup sempre se conecta ao vpn.robybaggio-corp.com, que resolve para um IP único, ou é possível que o túnel do dispositivo e o túnel do usuário tentem se conectar a dois servidores diferentes?
Como o SSTP usa SSL/TLS por baixo dos panos: você verificou se o certificado do servidor é válido e pode ser verificado em todos os casos? Isso pode ser algo tão simples quanto o cliente não conseguir verificar o certificado do servidor porque já faz tempo que viu a CA CRL e a CRL está no LDAP e não pode ser acessada sem o túnel.
Basicamente: A melhor abordagem é reduzir as circunstâncias. Comece a acompanhar as circunstâncias em que esses problemas acontecem, e quanto mais você souber de quando e onde acontece, mais fácil será determinar a causa raiz.
Mesmo que o resultado seja “pode acontecer com qualquer um, a qualquer momento”, você o reduziu às configurações comuns do ambiente do seu cliente Windows. Isso ainda é uma redução massiva nas possíveis fontes de erro.
Já tentei isso, e então o problema não ocorre. Mas precisamos usar SSTP, portanto alterar para qualquer outra coisa além de Automático não é uma opção.
Não é um problema com a rede em si, pois o problema ocorre apenas ocasionalmente, e ocorre independentemente da rede em que o usuário está. Ele também se resolve sozinho, especialmente ao reiniciar.
Não consigo detectar nenhum padrão. O usuário pode experimentar o problema, e então de repente ele funcionará na mesma rede.
Os túneis do dispositivo e do usuário apontam para o mesmo alvo, mas com FQDN diferente, o endereço IP é o mesmo. Com Wireshark, é possível visualizar as tentativas de conexão no servidor VPN. Então, a conectividade de rede entre cliente e servidor está definitivamente presente.
CRL é acessível na internet. O certificado do servidor está OK, pois 95% das conexões funcionam bem.
Richard Hicks escreveu sobre um problema semelhante, mas lá o IKEv2 é usado, não SSTP (como no nosso caso),