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?

Solution 1

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).

Solution 2

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.

Solution 3

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

Comments

[Steve Townsend]

You may garner further clues by seeing the debug output. Try running debug crypto isakmp and debug crypto ipsec

[Barak Gall]

Aha. I should do some Cisco studying. That points me to "IPSEC(validate_transform_proposal): proxy identities not supported", which seems to indicate I don't have my access-list policies set up completely right. I'm not out of the water yet, but I'm gettin' there. I'll read up a little bit on policy requirements for IPsec VPNs.

[Barak Gall]

Aye, I've seen the same with other devices, but figured since it was documented by both Cisco and Juniper, it wouldn't be too hard. I'll keep messing with the proposals and hopefully figure it out if I don't get another answer here, because this customer probably won't approve more hardware :)

[Null Route]

kb.juniper.net/KB6168 Summary: Received notify message for DOI <1> <14> < no_proposal_chosen > Problem or Goal: Environment: * IKE Phase 1 negotiation successful * Phase 2 initiated negotiation before the <NO_PROPOSAL_CHOSEN> message appeared Symptoms & Errors: * Received notify message for DOI <1> <14> <NO_PROPOSAL_CHOSEN> * IKE Phase 2 negotiation fails Solution: If phase 2 initiated, and you get the message, this indicates a mismatch in proposals between the two peers. Chances are, one side has nopfs, while the other side has perfect forward secrecy enabled.

[Tom O'Connor]

It's not FUD, it's personal experience.

[Barak Gall]

set ike p1-proposal "ToCorpOffice" preshare group2 esp 3des sha-1 second 3600 set ike p2-proposal "ToCorpOffice" group2 esp 3des sha-1 second 26400 Looks like both are using DH group 2, 3des/sha-1, hence my confusion that it's not working. I agree that it's a user error "not knowing how to do so on that device". I've generally setup site-to-site's on sonicwalls or junipers in homogenous environments. This is the second juniper->other VPN config I've attempted, and when the first one failed, they bouth another multitech router for their VPN :P

[Barak Gall]

mikeyb's suggestion to enable logging on the PIX seems to be pointing me in the right direction. Looks like the PIX has policy config issues. I didn't know how to access the logs, so I was just going by the Juniper's log. Still working on it, though.