A VPN baseada em política Cisco PIX para Juniper Netscreen falha na proposta da Fase 2

Question

Eu segui as instruções para configurar uma VPN entre um dispositivo netscreen e um Cisco PIX, conforme indicado pela [netscreen to PIX VPN] da Cisco. link .

As únicas diferenças são que estou executando o PIX 6.3 (5) e o Juniper Netscreen 6.1.0r2.0 (Firewall + VPN). Eu segui as duas configurações exatamente, e quando tento me conectar, o Juniper retorna com:

2010-02-21 12:54:28  information IKE: Removed Phase 2 SAs after receiving a notification message. 
2010-02-21 12:54:28  information IKE pix_public_IP: Received a notification message for DOI 1 14 NO-PROPOSAL-CHOSEN. 
2010-02-21 12:54:28  information IKE pix_public_IP Phase 2: Initiated negotiations. 

No Netscreen, criei uma proposta da Fase 2 chamada ToCorpOffice usando o DH Group # 2, 3DES-CBC e SHA-1, e ao configurar o AutoKey IKE, escolhi ToCorpOffice e removi todas as outras transformações. Eu acredito que eu configurei o mesmo no PIX com:

sysopt connection permit-ipsec
crypto ipsec transform-set mytrans esp-3des esp-sha-hmac
crypto map mymap 10 ipsec-isakmp
crypto map mymap 10 match address nonat
crypto map mymap 10 set pfs group2
crypto map mymap 10 set peer netscreen_public_ip
crypto map mymap 10 set transform-set mytrans
crypto map mymap interface outside

Salvo isso e reinicializado, aqui estão as informações do cryptomap:     PIX-FW1 # mostra mapa de criptografia

Crypto Map: "mymap" interfaces: { outside }

Crypto Map "mymap" 10 ipsec-isakmp
    Peer = netscreen_public_ip
    access-list nonat; 1 elements
    access-list nonat line 1 permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0 (hitcnt=0)
    Current peer: netscreen_public_ip
    Security association lifetime: 4608000 kilobytes/28800 seconds
    PFS (Y/N): Y
    DH group:  group2
    Transform sets={ mytrans, }
PIX-FW1#

Alguma ideia do motivo pelo qual estou recebendo um erro NO-PROPOSAL-CHOSEN?

    

Answer 1

Na maioria das vezes que vi esse problema, isso ocorreu devido à incompatibilidade do domínio de criptografia (ID de proxy). Como você está usando uma VPN baseada em política no lado da Juniper e não uma VPN baseada em rota, verá que o lado da Juniper tenta configurar as SAs IPSec que correspondem às políticas. Por exemplo, se sua política do Juniper se parece com:

set policy id 50 from "Untrust" to "Trust" "ext-192.168.1.50" "int-192.168.2.50" "HTTP"...

A configuração da VPN baseada em políticas espera que o ASA tente estabelecer uma SA IPSec de host para host que vai de 192.168.1.50 a 192.168.2.50, enquanto o ASA está tentando estabelecer um túnel que vai de 192.168. 2.0 / 24 a 192.168.1.0/24.

Não sei ao certo se esse é o caso da sua configuração porque você não publica as políticas do lado do Juniper, mas esse é o problema que eu mais vi com sintomas semelhantes aos seus. A solução mais fácil seria modificar a lista de acesso no ASA para coincidir com as políticas no firewall da Juniper (com a ressalva de que ainda precisa ser "permitir ip" em vez de especificar protocolos L4 +, já que você está especificando apenas o proxy ID).

    

Answer 2

adicione sub-redes locais e remotas no id do proxy - isso fará com que funcione

    

Answer 3

Meu fornecedor queria ver todo o meu tráfego proveniente de um endereço IP. Configurei uma política baseada em rota, com Tunnel.1 e Loop.1, criei o Loop com um / 26 que o IP NAT de saída estava no intervalo (eles especificaram um endereço que queriam ver meu tráfego e era o IP de transmissão para todos os intervalos até que eu fizesse um / 26). Fiz meu DIP na interface do túnel (eles especificaram 1 IP, então o DIP foi de 172.28.1.95 a .95), e criei políticas para combinar com o Cisco Crypto_Map com a tradução do meu DIP de saída.

Parte complicada é que eu tive que criar Fase II individual (IKE AutoKey VPNs) e usar os IDs de proxy para corresponder ao crypto_map deles. Quando fiz a primeira Fase II, aquela funcionou. Uma vez que fiz mais de um, falhou.

Para consertar isso, eu tive que endereçar um endereço GW para a rota para os endereços que eu estava conectando (em vez de apenas dizer ir para baixo tunnel.1 interface, tinha que fazer isso mais um IP GW) e depois no túnel .1 interface teve que fazer Next Hop Tunnel Binding. Eu não acho que você verá isso como uma opção até que você crie uma segunda Fase II e ligue-a à interface do túnel, porque se você tiver apenas um túnel, simplesmente não precisará dele. Então, para cada entrada no domínio de criptografia (crypto_map) (e para cada fase que eu tive que configurar) eu criei uma entrada NHTB que tinha IP do lado remoto IP (novamente do crypto_map) com entrada VPN sendo o apropriado VPN da Fase II.

    

Answer 4

Não é apenas a resposta de Tom O'Connor que não ajuda, é FUD. Os dispositivos Juniper são como qualquer outro dispositivo, se você estiver configurando um dispositivo que implemente corretamente a especificação IPSec, a única dificuldade é não saber como fazer isso no dispositivo.

Experimente o artigo sobre o KB da Juniper para solucionar problemas de VPNs. Isso pode ser mais útil.

link

Como é sua configuração SSG?

    

Answer 5

Eu recebi este erro depois que meu Netscreen tinha o combo de endereço IP / máscara de rede local errado.

    

Answer 6

A Juniper VPN pode ser notoriamente difícil de convencer a conversar com outros dispositivos. IME, eles só ficam muito felizes quando falam com outros dispositivos da Juniper.

Eu suspeito que isso possa ser algo similar.