Cisco PIX to Juniper Netscreen Policy-based VPN fails Phase 2 Proposal

Question

I've followed the instructions to configure a VPN between a netscreen device and a Cisco PIX as directed by Cisco's [netscreen to PIX VPN]http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00801c4445.shtml article.

The only differences are that I'm running PIX 6.3(5) and Juniper Netscreen 6.1.0r2.0 (Firewall+VPN). I followed both configurations exactly, and when I try to connect, the Juniper returns with:

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. 

On the Netscreen, I've created a Phase 2 Proposal called ToCorpOffice using DH Group#2, 3DES-CBC, and SHA-1, and when configuring the AutoKey IKE, I chose ToCorpOffice and removed all other transforms. I believe I've configured the same on the PIX with:

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

Saved that and rebooted, so here's the cryptomap info: 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#

Any idea why I'm getting a NO-PROPOSAL-CHOSEN error?

Answer 1

add local and remote subnets in the proxy id - that will get it working

Answer 2

Most times I've seen this problem, it was due to encryption domain (proxy ID) mismatch. Because you're using a policy-based VPN on the Juniper side and not a route-based VPN, you're going to see the Juniper side try to set up IPSec SAs that match the policies. For example, if your Juniper policy looks like:

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

The policy-based VPN config will expect the ASA to try to establish a host-to-host IPSec SA that goes from 192.168.1.50 to 192.168.2.50, while the ASA is trying to establish a tunnel that goes from 192.168.2.0/24 to 192.168.1.0/24.

I can't know for sure that this is the case with your configuration because you don't post the policies from the Juniper side, but this is the problem I've seen most often with symptoms similar to yours. The easiest solution would be to modify the access-list on the ASA to match the policies on the Juniper firewall (with the caveat that it still needs to be "permit ip" instead of specifying L4+ protocols, since you're specifying just the proxy ID).

Answer 3

My vendor wanted to see all my traffic coming from one IP address. I set up a route based policy, with Tunnel.1 and Loop.1, created the Loop with a /26 that the outbound NAT IP was in the range (they specified an address they wanted to see my traffic and it was the broadcast IP for all ranges until I made it a /26). I made my DIP on the tunnel interface (they specified 1 IP, so the DIP was 172.28.1.95 to .95), and created policies to match their Cisco Crypto_Map with source translation of my outbound DIP.

Tricky part was that I had to created individual Phase II's (IKE AutoKey VPNs) and use the proxy ID's to match their crypto_map. When I made the first Phase II, that one worked. Once I made more then one, it failed.

To fix it, I had to address a GW address to the route's to the addresses I was connecting to (instead of just saying go down tunnel.1 interface, had to do that plus a GW IP) and then on the tunnel.1 interface had to do Next Hop Tunnel Binding. I don't think you'll even see this as an option until you create a second Phase II and bind it to the tunnel interface, because if you only have one tunnel, you simply don't need it. So for each entry in the encryption domain (crypto_map) (and for that matter each Phase II i had to set up) I created an NHTB entry that had IP of the remote side IP (again from their crypto_map) with VPN entry being the appropriate Phase II VPN.

Answer 4

Not only Tom O'Connor's answer not helpful, it is FUD. Juniper devices are just like any other device, if you are setting up a device that implements the IPSec spec properly the only difficulty comes from not knowing how to do so on that device.

Try the article on the Juniper KB on troubleshooting VPNs. This might be more helpful.

http://kb.juniper.net/index?page=content&id=KB9221

What does your SSG config look like?

Answer 5

I got this error after my Netscreen had the wrong local IP address / netmask combo.

Answer 6

Juniper VPN can be notoriously difficult to convince to talk to other devices. IME, they're only really happy when talking to other Juniper devices.

I suspect that this might be something similar.