Windows Server FIrewall (2012) Problemas no túnel Ipsec

3

Eu sou novo em túneis Ipsec. Eu criei com sucesso um túnel para um roteador externo da Cisco usando uma chave pré-compartilhada em um fornecedor.

Em Endpoints 1: Eu tenho o endereço IP dos servidores e o endereço IP dos servidores remotos que pretendo conectar.

No Endpoint 2: Eu tenho os mesmos endereços IP acima

No endpoint do túnel ipsec listei o endereço IP dos servidores e o endpoint 2 que listei o roteador Cisco.

O túnel aparece. (Seu visível sob monitoramento e no modo principal e modo rápido) Além disso, o fornecedor confirma que eles podem ver nossa conexão.

No entanto, quando tentamos conectar a um dos servidores em sua rede, listados no terminal 1 e 2 acima, ele não se conecta.

O fornecedor alega que eles têm outros clientes conectados dessa maneira e não é um problema do lado deles.

Eu tentei rastrear o tráfego no wireshark, mas o wireshark só vê o tráfego se eu desabilitar o túnel Ipsec.

EDIT: Eu posso ver o tráfego de e para o ponto de extremidade do túnel quando tento o telnet em um servidor atrás do ponto de extremidade do túnel. No entanto, a sessão do telnet é excedida antes de ser estabelecida.

Alguma idéia?

    
por Wize 27.07.2015 / 10:49

2 respostas

2

Eu passei por este artigo para entender melhor o que é sua configuração. Seu computador local (ou o servidor do qual o túnel será iniciado) deve estar listado em "Endpoint 1", bem como "Local Tunnel Computer". A caixa "computador de túnel remoto" deve ter o endereço IP do seu roteador onde o túnel está terminado. Os servidores aos quais você deseja se conectar na outra extremidade devem estar listados em "Endpoint 2".

Como você pode negociar com êxito associações de segurança, não acredito que sejam necessárias alterações na configuração do seu túnel. No entanto, verifique o seu endereço IP local e remoto. Nenhum tráfego será gerado se houver um erro nesses filtros. Se possível, tente iniciar o tráfego para seus endpoints remotos e execute o Wireshark com filtros apropriados.

EDIT: Estou anexando uma captura de tela aqui do tráfego IPsec capturado no Wireshark. Você pode ver claramente as associações de segurança do Modo Principal sendo estabelecidas primeiro e o Modo Rápido sendo estabelecido sempre que houver tráfego fluindo pelo túnel. Eu intencionalmente removi as colunas de origem e destino.

    
por 27.07.2015 / 15:04
0

Também tenho este problema (avaliação do Windows Server 2012 R2) e resolvi-o com esta solução alternativa . O problema ocorre quando você habilitou o NAT na interface da Internet para acesso à Internet da LAN local. O tráfego gerado na LAN local com o destino da LAN remota é NATted antes da criptografia. A Cisco recebe esse pacote criptografado, descriptografa-o, mas o IP de origem do pacote descriptografado é o endereço IP público do Windows Server. Como isso é um erro, o roteador Cisco descarta o pacote e aumenta a contagem de erros. Você pode ver este contador no roteador Cisco com o comando show crypto ipsec sa detail e o contador aparece em pkts decaps failed (rcv) . Além disso, você pode ver os contadores nas estatísticas NAT no Windows Server.

Solução: no Windows Server cria uma rota estática para a LAN remota por meio da interface de loopback (na linha de comando do DOS). Use a opção -P para tornar a rota permanente (persistente para reiniciar). Por exemplo, se a LAN remota for 10.245.0.0/16, o comando é:

route -P add 10.245.0.0 mask 255.255.0.0 0.0.0.0 if 1

Infelizmente, não consegui encontrar outro método para evitar a NAT do tráfego destinado à LAN remota através do túnel ipsec.

    
por 18.09.2018 / 03:55