基于Cisco PIX到Juniper Netscreen策略的VPN第二阶段提案失败

Question

我按照思科netscreen到PIX VPN文章的指示，在netscreen设备和Cisco之间配置VPN。

唯一的区别是我运行的是PIX 6.3(5)和Juniper 6.1.0r2.0 (Firewall+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、3 removed和SHA-1创建了一个名为ToCorpOffice的第二阶段方案，在配置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#显示密码映射

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#

你知不知道为什么我会有一个没有选择的错误？

Answer 1

大多数时候我都看到了这个问题，这是由于加密域(代理ID)不匹配造成的。因为您在Juniper端使用的是基于策略的VPN，而不是基于路由的VPN，所以您将看到Juniper端尝试设置与策略匹配的IPSec SAs。例如，如果您的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)。

Answer 2

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

Answer 3

我的供应商希望看到我所有的流量来自一个IP地址。我设置了一个基于路由的策略，使用Tunnel.1和Loop.1创建了一个用/26创建的循环，该循环显示出站NAT IP在范围内(他们指定了一个地址，他们希望看到我的流量，它是所有范围的广播IP，直到我使它成为/26)。我是在隧道接口(他们指定了一个IP，所以DIP是172.28.1.95到.95)上做的，创建了一些策略来匹配他们的Cisco Crypto_Map和我出站DIP的源代码转换。

棘手的部分是，我必须创建单独的第二阶段(IKE AutoKey VPN)，并使用代理ID来匹配他们的crypto_map。当我完成第一阶段第二阶段的时候，那一阶段起了作用。一旦我做了不止一个，它就失败了。

为了解决这个问题，我必须将GW地址定位到我所连接的地址(而不是仅仅说沿着隧道1接口，必须加上一个GW IP)，然后在隧道1接口上进行Next Hop隧道绑定。我认为，在创建第二阶段并将其绑定到隧道接口之前，您甚至不会将其视为一种选择，因为如果您只有一个隧道，则根本不需要它。因此，对于加密域(crypto_map)中的每个条目(以及为此，我必须设置的每个第二阶段)，我创建了一个NHTB条目，该条目具有远程侧IP (同样来自他们的crypto_map)的IP，其中VPN条目是合适的第二阶段VPN。