none
Erro ao conectar VPN RRS feed

 > 

  • Pergunta

  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Boa tarde pessoal,

    Estou com um problema em um servidor vpn.. quando tento conectar aparece o seguinte erro "806"

    "A conexão VPN entre o computador e o servidor VPN não pôde ser concluída. A causa mais comum para essa falha é que pelo menos um dispositivo (por exemplo, um firewall ou um roteador) entre o computador e o servidor VPN não está configurado para permitir pacotes do protocolo GRE (encapsulamento de roteamento genérico) de Internet. Se o problema persistir, contate o administrador de rede ou provedor. "

    se usar o telnet ip_do_server 1723  ele conecta.
    criando uma conexão na rede interna conecta tbm.

    apenas externo dá este erro.

    Podem me dar um help?

    segunda-feira, 27 de setembro de 2010 20:49
    |

Respostas

  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Se for algum firewall que está barrando por Smart Defense, IPS, ou qualquer outra forma de checagem que não porta, você não consegue simular este tráfego com telnet. Porque o tráfego teria que ser encapsulado, o que o telnet não vai fazer. Você tem acesso ao firewall ou pode consultar seu administrador?

    Se for este  o caso, depende um pouco do modelo de firewall/router, mas é checando logs.

     

    Se foi útil, não se esqueça de Marcar como Resposta. Cláudio Costa - http://claudio-costa.blogspot.com
    segunda-feira, 27 de setembro de 2010 23:32
    |
    Moderador
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Padilha,

    as portas são essas sinalizadas pelos colegas. Agora o Cláudio falou algo muito importante, existem soluções que analisam o comportamento dos protocolos, e mesmo com as portas liberadas, o tráfego pode ser barrado.

    Por isso, tenha certeza que as devidas portas estão liberadas no seu Firewall e o NAT estático devidamente configurado para o IP do servidor interno. Após isso, caso o erro persista, siga a dica do Cláudio e cheque soluções do tipo e veja se elas podem estar influenciando.

    Att,

    Fabiano Barreira

    MCP + MCDST + MCSA on Windows Server 2003 + MCTS + MCITP
    terça-feira, 28 de setembro de 2010 00:22
    |

Todas as Respostas

  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Boa tarde Padilha,

    pelo que vc citou, seu problema está no Firewall. Valide as configurações da sua VPN nesse KB e certifique-se de que existe NAT no seu Roteador de Internet ou no seu Firewall para o IP interno do seu servidor de VPN:

    http://technet.microsoft.com/pt-br/library/cc737500(WS.10).aspx

    Att,

    Fabiano Barreira

    MCP + MCDST + MCSA on Windows Server 2003 + MCTS + MCITP
    segunda-feira, 27 de setembro de 2010 21:01
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Boa Tarde Padilha, concordo com o amigo Fabiano. Recentemente em um cliente, o firewall, mesmo com a porta 1723 aberta, tinha uma espécie de análise eurística ou Smart Defense (para os que usam checkpoint) que bloqueava pacotes GRE.  Você tem como verificar isso?

     

    Se foi útil, não se esqueça de Marcar como Resposta. Cláudio Costa - http://claudio-costa.blogspot.com
    segunda-feira, 27 de setembro de 2010 21:14
    |
    Moderador
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Padilha,

    Para o bom funcionamento da VPN é obrigatório liberar as duas portas PPTP 1723 e GRE 47.

    Liberando estas duas portas fazendo o redirecionamento no Firewall, vai funcionar.

    abs

     

    ...Carlos Henrique | MCSA WINDOWS SERVER 2003...
    segunda-feira, 27 de setembro de 2010 21:23
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Pessoal...

    tem alguma outra maneira de testar a porta 47 além do telnet? pois tanto externo e interno ele conecta... e o protocolo que estou utilizando é PPTP..

    segunda-feira, 27 de setembro de 2010 22:47
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Se for algum firewall que está barrando por Smart Defense, IPS, ou qualquer outra forma de checagem que não porta, você não consegue simular este tráfego com telnet. Porque o tráfego teria que ser encapsulado, o que o telnet não vai fazer. Você tem acesso ao firewall ou pode consultar seu administrador?

    Se for este  o caso, depende um pouco do modelo de firewall/router, mas é checando logs.

     

    Se foi útil, não se esqueça de Marcar como Resposta. Cláudio Costa - http://claudio-costa.blogspot.com
    segunda-feira, 27 de setembro de 2010 23:32
    |
    Moderador
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Já mandei email para o meu colega que administra o firewall pedindo para liberar a  porta 47 .. eu sei q não tem smard defense, ips.. mas vou conferir e amanha trago o report para vocês...
    terça-feira, 28 de setembro de 2010 00:11
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Padilha,

    as portas são essas sinalizadas pelos colegas. Agora o Cláudio falou algo muito importante, existem soluções que analisam o comportamento dos protocolos, e mesmo com as portas liberadas, o tráfego pode ser barrado.

    Por isso, tenha certeza que as devidas portas estão liberadas no seu Firewall e o NAT estático devidamente configurado para o IP do servidor interno. Após isso, caso o erro persista, siga a dica do Cláudio e cheque soluções do tipo e veja se elas podem estar influenciando.

    Att,

    Fabiano Barreira

    MCP + MCDST + MCSA on Windows Server 2003 + MCTS + MCITP
    terça-feira, 28 de setembro de 2010 00:22
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Bom dia pessoal,

     

     Gostaria de agradecer a todos pelas dicas, o problema era o seguinte o administrador do firewall e o Gerente de TI aviam desabilitado o serviço pptp do firewall (mikrotik).

     

    Mais uma vez muito obrigado.

    • Marcado como Resposta Padilha terça-feira, 28 de setembro de 2010 12:56
    • Não Marcado como Resposta Cláudio CostaModerator terça-feira, 28 de setembro de 2010 15:30
    terça-feira, 28 de setembro de 2010 12:56
    |