Criptografia IPsec do Windows 2008 R2 no modo de encapsulamento, hosts na mesma sub-rede

Question

No Windows, parece haver duas maneiras de configurar o IPsec:

1. O snap-in Gerenciamento de Diretivas de Segurança de IP do MMC (parte de secpol.msc , introduzido no Windows 2000).
2. O snap-in Firewall do Windows com segurança avançada do MMC ( wf.msc , introduzido no Windows 2008 / Vista).

Minha pergunta é sobre o nº 2: eu já descobri o que preciso saber para o nº 1. (Mas eu quero usar o "novo" snap-in por seus recursos aprimorados de criptografia.)

Eu tenho dois computadores com o Windows Server 2008 R2 no mesmo domínio (membros do domínio), na mesma sub-rede:

server2  172.16.11.20
server3  172.16.11.30

Meu objetivo é criptografar toda a comunicação entre essas duas máquinas usando IPsec no modo de túnel , para que a pilha de protocolos seja:

• IP
• ESP
• IP
• … etc.

Primeiro, em cada computador, criei uma regra de segurança de conexão :

• Ponto final 1: (endereço IP local), por exemplo, 172.16.11.20 para server2
• Endpoint 2: (endereço IP remoto), por exemplo, 172.16.11.30
• Protocolo: Qualquer
• Autenticação: Exigir entrada e saída , Computador (Kerberos V5)
Túnel IPsec
• :
  • Conexões protegidas IPsec isentas
  • Nó de extremidade do túnel local: Qualquer
  • Terminal de túnel remoto: (endereço IP remoto), por exemplo, 172.16.11.30

Neste ponto, eu posso ping de cada máquina, e o Wireshark me mostra a pilha de protocolos; no entanto, nada é criptografado (o que é esperado neste momento). Eu sei que não é criptografado porque o Wireshark pode decodificá-lo (usando a configuração Tentativa de detectar / decodificar cargas de ESP criptografadas NULL ) e o Monitor > Associações de segurança > A exibição Quick Mode mostra a criptografia ESP: None .

Em cada servidor, criei Entrada e Regras de saída :

• Protocolo: Qualquer
• Endereços IP locais: (endereço IP local), por exemplo, 172.16.11.20
• Endereços IP remotos: (endereço IP remoto), por exemplo, 172.16.11.30
• Ação: Permitir a conexão se for segura
  • Exigem que as conexões sejam criptografadas

O problema : embora eu crie as Inbound e Regras de saída em cada servidor para ativar a criptografia, os dados ainda estão passando pela conexão (embrulhado em ESP) com criptografia NULL. (Você pode ver isso no Wireshark.)

Quando chega ao terminal de recebimento, ele é rejeitado (presumivelmente porque não está criptografado). [E, desabilitar a regra Inbound na extremidade receptora faz com que ela seja bloqueada e / ou bluescreen - diversão!] O log do Windows Firewall diz, por exemplo:

2014-05-30 22:26:28 DROP ICMP 172.16.11.20 172.16.11.30 - - 60 - - - - 8 0 - RECEIVE

Eu tentei variar algumas coisas:

• Nas Regras , defina o endereço IP local para Qualquer
• Alternando a configuração Conexões protegidas IPsec isentas
• Desativando regras (por exemplo, desativando um ou ambos os conjuntos de regras de entrada ou saída)
• Alterando o protocolo (por exemplo, apenas para TCP)

Mas, realisticamente, não há muitos botões para girar.

Alguém tem alguma ideia? Alguém já tentou configurar o modo de túnel entre dois hosts usando o Firewall do Windows?

Eu consegui configurá-lo com sucesso no modo de transporte (ou seja, sem túnel) usando exatamente o mesmo conjunto de regras, então estou um pouco surpreso por ele não ter apenas o Just Work ™ o túnel adicionado.

    

Answer 1

Depois de muita investigação e um caso de suporte com a Microsoft, encontrei uma resposta.

O truque é: não crie nenhuma Inbound ou Regras de saída para criptografia. Apenas crie uma regra de segurança de conexão (para o túnel). Em seguida, defina os padrões de IPsec para o firewall criptografar todas as conexões habilitadas para IPsec .

Faça o seguinte em cada extremidade do túnel:

1. Crie uma regra de segurança de conexão :

   • Endpoint 1: (endereço IP local), por exemplo, 172.16.11.20
   • Endpoint 2: (endereço IP remoto), por exemplo, 172.16.11.30
   • Protocolo: Qualquer
   • Autenticação: Exigir entrada e saída, computador (Kerberos V5)
   Túnel IPsec
   • :
     • Conexões protegidas IPsec isentas
     • Nó de extremidade do túnel local: Qualquer
     • Terminal de túnel remoto: (endereço IP remoto), por exemplo, 172.16.11.30

2. Força todas as conexões IPsec a serem criptografadas:

   1. Abra as propriedades principais do firewall (clique com o botão direito do mouse em Firewall do Windows com Segurança Avançada > Propriedades…)
   2. Na guia Configurações IPsec , sob padrões IPsec , clique em Personalizar…
   3. Em Proteção de dados (Modo rápido) , selecione Avançado e clique em Personalizar…
   4. Marque a caixa de Exigir criptografia para todas as regras de segurança de conexão que usam essas configurações .
   5. Ajuste quaisquer outras configurações (por exemplo, você pode querer remover o 3DES como um protocolo) e, em seguida, clique em OK.

Se você criou anteriormente quaisquer regras de entrada / saída para criptografia, desative-as ou exclua-as.

Isso funciona bem. Sua única desvantagem é que ele força a criptografia em todas as conexões IPsec; você não pode mais ter uma combinação de conexões somente criptografadas e protegidas por integridade.

Como você sabe que o tráfego é realmente tunnelled (ou seja, o ESP está carregando carga IP em vez de, por exemplo, TCP)? Você pode verificar isso com o antigo MMC IPsec ( Gerenciamento de Diretivas de Segurança IP ou secpol.msc ).

• Em um servidor, crie um túnel usando as instruções acima para o WFAS.
• Em outro servidor, crie um túnel usando o "antigo" IPsec MMC.
• Esses dois devem se comunicar sem problemas.
• Se você alternar a diretiva IPsec "antiga" para o modo de transporte (ou seja, remover o encapsulamento), a conexão será interrompida. É assim que você pode dizer que a conexão do WFAS é realmente um túnel.