Compartilhar via

Tunel VPN P2S, bloqueado para troca.

Eduardo Silva 0 Pontos de reputação
2026-03-24T18:21:18.5833333+00:00

Tenho uma Virtual network gateway (VPN) com SKU : Básico.
tinha configurado uma P2S, com SSTP ( SSL) , porém o certificado venceu e tive que fazer do Zero as configurações da P2S, e agora ele está Bloqueado em IKEv2
Imagem do usuário

Gateway de VPN do Azure
Gateway de VPN do Azure

Um serviço do Azure que habilita a conexão de redes locais com o Azure por meio de redes virtuais privadas site a site.


2 respostas

Classificar por: Mais útil
  1. Ganesh Patapati 11,915 Pontos de reputação Equipe Externa da Microsoft Moderador
    2026-04-02T19:12:32.34+00:00

    Olá Eduardo Silva

    Traduzi este texto do inglês para o português, então peço desculpas por quaisquer erros gramaticais.

    O Azure VPN Gateway Basic SKU não suporta IKEv2 para conexões Point-to-Site (P2S).

    NOTA: Quando a configuração P2S foi recriada após o certificado expirar, o Azure tentou ativar o IKEv2 (agora comumente ativado por padrão). Como o SKU Básico não suporta IKEv2, o Azure o marca corretamente como Bloqueado por design.Como solução alternativa

    Se você continuar usando o SKU Básico, configure a VPN Point-to-Site para usar SSTP (SSL) apenas definindo o tipo de túnel (garantindo que o IKEv2 não esteja selecionado), enviando o novo certificado raiz, gerando e instalando novos certificados de cliente e baixando novamente o pacote cliente VPN, pois essa é a única configuração P2S suportada no SKU Básico e funcionará como esperado.

    Ou então,

    Recrie seu gateway com um SKU mais alto (se IKEv2 for necessário)

    Se esse cenário exigir IKEv2 (para desempenho, compatibilidade de dispositivos ou preparação para o futuro):

    Nota: SKU básico não pode ser atualizado no local. O gateway deve ser excluído e recriado com um SKU maior.

    Imagem do usuário


    Você pode, por favor, nos atualizar se o plano de ação fornecido foi útil?

    Se houver dúvidas ou preocupações adicionais, por favor, nos avise e tentaremos respondê-las.

    Se responderem sua pergunta, clique em "Upvote" e clique em "Aceitar resposta", o que pode ser útil para outros membros da comunidade que estejam lendo este tópico.

    Esta resposta foi útil?


  2. Venkatesan S 8,315 Pontos de reputação Equipe Externa da Microsoft Moderador
    2026-03-24T18:38:27.0766667+00:00

    Olá Eduardo Silva,

    Eu traduzi este texto do inglês para o português, então peço desculpas por quaisquer erros gramaticais.

    Obrigado por entrar em contato no fórum de perguntas e respostas da Microsoft.

    tinha configurado uma P2S, com SSTP ( SSL) , porém o certificado venceu e tive que fazer do Zero as configurações da P2S, e agora ele está Bloqueado em IKEv2

    Para um Gateway de Rede Virtual com SKU Básico, o Azure não permite mais configurar novos túneis P2S usando SSTP – somente o IKEv2 está disponível na nova experiência.

    É por isso que o campo “Tipo de túnel” está acinzentado e travado no IKEv2 na sua captura de tela.

    • As configurações SSTP P2S existentes no plano Básico podem continuar funcionando, mas, após recriar a configuração P2S, o portal forçará o uso exclusivo do IKEv2.
    • Para usar o SSTP novamente (ou IKEv2 + OpenVPN com mais opções), você deve:
      • Criar um novo gateway VPN com uma SKU compatível (por exemplo, VpnGw1 ou superior; o plano Básico é legado).
      • Reconfigurar suas configurações P2S (certificados raiz, pool de endereços, tipos de túnel).
      • Baixar novos perfis de cliente VPN e redistribuí-los aos usuários.

    Atualizar 1:

    O IKEv2 funciona para RDP com certificado para acesso ao ambiente? Se sim qual o procedimento?

    Sim, o IKEv2 funciona perfeitamente para acesso RDP em nossa configuração de VPN ponto a site (P2S) do Azure usando certificados de cliente. Ele estabelece um túnel seguro que roteia o tráfego RDP para seus recursos de VNet (por exemplo, VMs em IPs privados), fornecendo o mesmo acesso ao ambiente que o SSTP, sem problemas de compatibilidade em clientes Windows modernos.

    Visão geral do procedimento:

    1. Preparar certificados: Gere um certificado de CA raiz e certificados de cliente (PowerShell: New-SelfSignedCertificate). Exporte a chave pública do certificado raiz (Base64).
    2. Configuração do Gateway (Portal > Gateway VPN > Configuração P2S):
      • Tipo de túnel: IKEv2.
      • Autenticação: Certificado Azure.
      • Faça upload do root cert, defina pool de endereços (ex.: 10.0.1.0/24).
      • Baixe o ZIP do cliente VPN.
    3. Configuração do cliente (Windows):
      • Instale root cert no store "Trusted Root Certification Authorities".
      • Instale cert de cliente no store "Personal".
      • Importe o perfil VPN do Azure e conecte.
    4. RDP: A partir do IP da VPN, acesse o IP privado da VM via RDP. Atualize os NSGs, se necessário (permita a porta 3389 do pool P2S).
    5. Verifique o túnel com o ipconfig (mostra o IP P2S) e, em seguida, inicie o RDP.

    Observação: O SKU Basic tem limitações — considere upgrade para VpnGw1 para suporte completo e confiabilidade no IKEv2.

    Atualizar 2 :

    O erro 798 ("Um certificado não pode ser encontrado" ou "A remote peer não respondeu") no cliente VPN Azure com IKEv2 geralmente indica problemas com certificados mal configurados ou root cert não processado corretamente no gateway. Vamos resolver isso passo a passo.

    Diagnóstico Imediato

    No seu Windows VPN setup:

    • "Certificado do cliente necessário" está
    • Mas o Azure VPN Client não valida o root certificate chain completamente.

    Solução Passo a Passo

    1. Verificar Root Certificate no Gateway (CRÍTICO)
    Portal > VPN Gateway > Point-to-site configuration > Certificados raiz
    
    • Deve mostrar Data + Thumbprint
    • Se só "Data", Delete e re-upload o root cert Base64 only (sem -----BEGIN CERTIFICATE-----)
    Exemplo correto:
    MIICoTCCAYkCAgJkVjdlYm...
    (Não: -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----)
    
    1. Client Certificate - Verificações no Windows:
    # Certificado CLIENTE deve ter:
    Get-ChildItem Cert:\CurrentUser\My | 
        Where-Object {$_.Subject -match "CN=cliente"} | 
        Select Subject, Thumbprint, HasPrivateKey
    # Root cert no Trusted Root:
    Get-ChildItem Cert:\CurrentUser\Root | 
        Where-Object {$_.Subject -match "CN=RootCA"}
    
    1. Recriar Root Cert Corretamente
    # PowerShell - Novo root CA
    $rootCert = New-SelfSignedCertificate -DnsName "P2SRootCA" -CertStoreLocation "Cert:\CurrentUser\My" -KeyExportPolicy Exportable -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" -KeyLength 4096 -NotAfter (Get-Date).AddYears(10)
    # Exportar PUBLIC KEY (somente para Azure)
    $base64 = [System.Convert]::ToBase64String($rootCert.RawData) -replace '\r\n',''
    Write-Output $base64 | Out-File -FilePath "RootCertBase64.txt"
    
    1. Reconfigurar P2S (Portal):
    1. Download VPN Client ZIP NOVO após upload cert
    2. Delete old .azurevpnconfig.xml
    3. Importar NOVO profile
    
    
    
    1. Teste Rápido de Conectividade
    # Testar UDP 500/4500 do cliente para gateway public IP
    Test-NetConnection -ComputerName <GatewayPublicIP> -Port 500
    Test-NetConnection -ComputerName <GatewayPublicIP> -Port 4500
    

    NSG Já Correto

    Ports 500/4500 liberados resolve firewall, mas erro 798 é certificado.

    Isso resolve 95% dos casos 798. Me envie screenshot do "Root certificates" no portal se persistir!

    Referência:

    Por favor, nos informe se as informações acima foram úteis ou se você precisa de mais ajuda com relação a este assunto.

    Por favor, não se esqueça de "Aceitar resposta" e "votar positivamente" sempre que a informação fornecida lhe for útil, isso pode beneficiar outros membros da comunidade.

    Esta resposta foi útil?


Sua resposta

As respostas podem ser marcadas como ‘Aceitas’ pelo autor da pergunta e ‘Recomendadas’ pelos moderadores, o que ajuda os usuários a saber a resposta que resolveu o problema do autor.