☰

Cisco PIX 到 Juniper Netscreen 基于策略的 VPN 未能通过第 2 阶段提案

tag-icon • tag-icon vpn cisco cisco-pix juniper netscreen
Cisco PIX 到 Juniper Netscreen 基于策略的 VPN 未能通过第 2 阶段提案

我已按照 Cisco 的 [netscreen 到 PIX VPN] 中的说明在 netscreen 设备和 Cisco PIX 之间配置 VPNhttp://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00801c4445.shtml文章。

唯一的区别是我正在运行 PIX 6.3(5) 和 Juniper Netscreen 6.1.0r2.0 (防火墙+VPN)。我严格遵循了这两种配置，当我尝试连接时，Juniper 返回：

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.

在 Netscreen 上，我使用 DH Group#2、3DES-CBC 和 SHA-1 创建了名为 ToCorpOffice 的第 2 阶段提案，并且在配置 AutoKey IKE 时，我选择了 ToCorpOffice 并删除了所有其他转换。我相信我已经在 PIX 上配置了相同的内容：

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

保存并重新启动，以下是加密图信息：PIX-FW1# show crypto map

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#

知道为什么我会收到 NO-PROPOSAL-CHOSEN 错误吗？

答案1

大多数情况下，我见过此问题，这是由于加密域（代理 ID）不匹配造成的。由于您在 Juniper 端使用的是基于策略的 VPN，而不是基于路由的 VPN，因此您将看到 Juniper 端尝试设置与策略匹配的 IPSec SA。例如，如果您的 Juniper 策略如下所示：

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

基于策略的 VPN 配置将期望 ASA 尝试建立从 192.168.1.50 到 192.168.2.50 的主机到主机 IPSec SA，而 ASA 则尝试建立从 192.168.2.0/24 到 192.168.1.0/24 的隧道。

我无法确定您的配置是否确实存在这种情况，因为您没有从 Juniper 端发布策略，但这是我最常看到的问题，症状与您的类似。最简单的解决方案是修改 ASA 上的访问列表以匹配 Juniper 防火墙上的策略（但需要注意的是，它仍然需要是“允许 ip”，而不是指定 L4+ 协议，因为您只指定了代理 ID）。

答案2

在代理 ID 中添加本地和远程子网 - 这将使其正常工作

答案3

我的供应商希望看到我的所有流量都来自一个 IP 地址。我设置了一个基于路由的策略，使用 Tunnel.1 和 Loop.1，创建了一个带 /26 的 Loop，出站 NAT IP 位于该范围内（他们指定了一个他们希望看到我的流量的地址，它是所有范围的广播 IP，直到我将其设为 /26）。我在隧道接口上创建了我的 DIP（他们指定了 1 个 IP，因此 DIP 为 172.28.1.95 到 .95），并创建了策略以将其 Cisco Crypto_Map 与我的出站 DIP 的源转换相匹配。

棘手的部分是我必须创建单独的第二阶段 (IKE AutoKey VPN) 并使用代理 ID 来匹配它们的 crypto_map。当我创建第一个第二阶段时，它成功了。一旦我创建多个，它就会失败。

为了解决这个问题，我必须将 GW 地址定位到我要连接的地址的路由（而不是只说沿着隧道 1 接口走，必须加上 GW IP），然后在隧道 1 接口上执行下一跳隧道绑定。我认为在创建第二个阶段 II 并将其绑定到隧道接口之前，您甚至不会看到这个选项，因为如果您只有一个隧道，您根本不需要它。因此，对于加密域 (crypto_map) 中的每个条目（以及我必须设置的每个阶段 II），我创建了一个 NHTB 条目，该条目具有远程端 IP 的 IP（同样来自它们的 crypto_map），VPN 条目是适当的阶段 II VPN。

答案4

我的 Netscreen 有错误的本地 IP 地址/网络掩码组合后出现此错误。

相关内容