Juniper SSG site to Site VPN with a PIX ASA issue



  • I’m trying to setup a VPN between our device which is Cisco ASA 5510 and our partners device which is a Juniper SSG-320M. Phase 2 appears to be setup as I get MM-ACTIVE on my ASA but I’m getting this error message in my PIX ASA log file:-

    Mar 23 2009 05:06:03 Pixasa : %ASA-4-402116: IPSEC: Received an ESP packet (SPI= 0x19415F54, sequence number= 0x1) from vpn_Partner (user= 210.1.28.226) to 203.5.124.43.  The decapsulated inner packet doesn’t match the negotiated policy in the SA.  The packet specifies its destination as 203.5.124.43, its source as vpn_Partner, and its protocol as 1.  The SA specifies its local proxy as 192.168.1.21/255.255.255.255/0/0 and its remote_proxy as 192.168.161.3/255.255.255.255/0/0.

    (For security reasons I have replaced names of devices and IP addresses in the above message with made up values).

    We have played around with phase 2 settings but to no avail.

    Juniper support told our partner that their Juniper SSG is not compatible with our PIX ASA, I wanted to verify this?

    Has anyone had issues with Juniper SSG and PIX ASA site to site VPN’s?

    Thanks
    Jayne



  • I found out that the group was wrong for phase 2. Now Phase 2 is complete but I cant get past the other side. I can ping the inside IP but I can’t get any further than that. I’m assuming that it’s an ACL issue.



  • Hi, the message suggests this to be a proposal mismatch issue. You have to confirm that the P2 proposals you have on the SSG and the crypto-map proposals in the ASA match with each other.



  • I’m having and issue with Phase 2. I’m receiving the error “Received a notification message for DOI 1 14 NO-PROPOSAL-CHOSEN.” on my SSG5. Does this have to do with an ACL on the ASA?



  • Hi There,

    I know it’s an old post but I have exact same issue which is being defined earlier on with same error message.

    Problem I have I can initiate VPN tunnel from ASA to juniper and traffic is passing without any problem but I can’t initate tunnel from Juniper side. I am using policy based VPN tunnels every thing was working fine until last week and out of nowhere this problme is being reported now. I manage firewall at both ends juniper and cisco asa all above solutions didn’t help me so if any one could point me to right direction then your help will be much appreciated.



  • Try turning off VPN Monitor on the Juniper side.  I had this same error and turning it off resolved the issue.



  • Thanks lithium381, I’ll check the ACLs then. Busy with other stuff right now, but will post back when I’ve looked into this.



  • joka  -
    on the cisco when creating the proxy-id’s for the VPN, it is done by associating crypto maps with an access list.

    for example, syntax is off the top of my head, forgive errors

    access-list extended 101 permit ip SOURCE mask DESTINATION mask

    where source is your LOCAL, and destination is REMOTE for the proxy ID statement.  if you get them mixed up and accidentally put the remote as source, and desitnation as local, the proxy IDs will not match and you will not properly form the VPN



  • Hello,

    I know this is an old thread by now, but I have the same issue, and have not been able to solve it so far. I’m on the Cisco end of a VPN tunnel that is working just fine, except for this error.

    By “access lists back to front”, was that on the Cisco side, and what was done to get rid of this issue?

    Would be great if anyone could provide a piece of code on how to set this up on the Cisco side in order for the error message to disappear.



  • Thanks it was the proxy ID’s my access list was back to front!  Ive fixed it and now it all works.



  • it’s most likely going to be a proxy ID issue
    do you know if the vpn on the Juniper side is a policy based or route based vpn ?
    How many networks ranges are involved in the VPN setup ?

    They may have to set up a policy based VPN on Juniper and use the policy objects to make the policy ID’s, but these policy ID’s need to match with the network-objects that are bound to the crypto map on the Cisco side

    If they use route based VPN, they need to set up a tunnel interface and enable proxy ID’s on the tunnel, and set up the values so they match with the network-objects.

    If the setup involves a many to many network range, they have to

    • set up multiple policies (to match with every network to network combination)
    • set up multiple tunnel interfaces

    see http://www.corelan.be:8800/index.php/2007/11/17/juniper-setting-up-an-ipsec-vpn-tunnel-between-a-juniper-netscreen-firewallvpn-device-and-a-cisco-vpn-device/ for more info


 

37
Online

38.4k
Users

12.7k
Topics

44.5k
Posts