PIX to Checkpoint VPN not completing phase 2 IKE

Yes I am familiar with that cisco doc and followed it to set up my config.

I think we should be routing OK. I can ping the outside interface of their CheckPoint. We have been able to connect  to their checkpoint via the SecuRemote client.

The host on the PIX side definitely points to the PIX as the default gateway. Everything goes through it. I can't imagine their side not being correct.

I don't have a Cisco support contract so I can't upgrade my OS AFAIK.

What does no-xauth mean?

Xauth is extended authentication, meaning once the tunnel is established, there is another exchange for username/password (like if you are using Radius authentication for clients). You do not want this in a LAN-LAN tunnel.

I see this in the exchange, so disabling it might help you:
>ISAKMP (0:0): Need XAUTH

I re-entered the isakmp key config line with no-xauth and no-config-mode
 
isakmp key ******** address xxx.xxx.xxx.xxx netmask 255.255.255.255 no-xauth no-config-mode
 
What does this mean, "IKMP_NO_ERR_NO_TRANS"?

The following is my debug. Still doesn't create the tunnel. (see "show isa sa" below).

VPN Peer: ISAKMP: Added new peer: ip:xxx.xxx.xxx.xxx Total VPN Peers:3
VPN Peer: ISAKMP: Peer ip:xxx.xxx.xxx.xxx Ref cnt incremented to:1 Total VPN Peers:3
ISAKMP (0): beginning Main Mode exchange
crypto_isakmp_process_block: src xxx.xxx.xxx.xxx, dest yyy.yyy.yyy.yyy
OAK_MM exchange
ISAKMP (0): processing SA payload. message ID = 0
 
ISAKMP (0): Checking ISAKMP transform 1 against priority 10 policy
ISAKMP:      encryption 3DES-CBC
ISAKMP:      hash MD5
ISAKMP:      default group 2
ISAKMP:      auth pre-share
ISAKMP:      life type in seconds
ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
ISAKMP (0): atts are acceptable. Next payload is 0
ISAKMP (0): SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
return status is IKMP_NO_ERROR
crypto_isakmp_process_block: src xxx.xxx.xxx.xxx, dest yyy.yyy.yyy.yyy
OAK_MM exchange
ISAKMP (0): processing KE payload. message ID = 0
 
ISAKMP (0): processing NONCE payload. message ID = 0
 
ISAKMP (0): ID payload
        next-payload : 8
        type         : 1
        protocol     : 17
        port         : 500
        length       : 8
ISAKMP (0): Total payload length: 12
return status is IKMP_NO_ERROR
crypto_isakmp_process_block: src xxx.xxx.xxx.xxx, dest yyy.yyy.yyy.yyy
OAK_MM exchange
ISAKMP (0): processing ID payload. message ID = 0
ISAKMP (0): processing HASH payload. message ID = 0
ISAKMP (0): SA has been authenticated
 
ISAKMP: Created a peer node for xxx.xxx.xxx.xxx
ISAKMP (0): beginning Quick Mode exchange, M-ID of -1061470206:c0bb4002IPSEC(key
_engine): got a queue event...
IPSEC(spi_response): getting spi 0x37500c7d(927992957) for SA
        from     xxx.xxx.xxx.xxx to    yyy.yyy.yyy.yyy for prot 3
 
return status is IKMP_NO_ERROR
ISAKMP (0): sending INITIAL_CONTACT notify
ISAKMP (0): sending NOTIFY message 24578 protocol 1
crypto_isakmp_process_block: src xxx.xxx.xxx.xxx, dest yyy.yyy.yyy.yyy
ISAKMP (0): processing NOTIFY payload 18 protocol 3
        spi 927992957, message ID = 1176345705
ISAKMP (0): deleting spi 2097958967 message ID = 3233497090
return status is IKMP_NO_ERR_NO_TRANS
Delta-PIX(config)# IPSEC(key_engine): request timer fired: count = 1,
  (identity) local= yyy.yyy.yyy.yyy, remote= xxx.xxx.xxx.xxx,
    local_proxy= 172.21.1.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 172.25.9.0/255.255.255.0/0/0 (type=4)
 
ISAKMP (0): beginning Quick Mode exchange, M-ID of -1116989248:bd6c18c0IPSEC(key
_engine): got a queue event...
IPSEC(spi_response): getting spi 0x7caba5c7(2091623879) for SA
        from     xxx.xxx.xxx.xxx to    yyy.yyy.yyy.yyy for prot 3
 
crypto_isakmp_process_block: src xxx.xxx.xxx.xxx, dest yyy.yyy.yyy.yyy
ISAKMP (0): processing NOTIFY payload 18 protocol 3
        spi 2091623879, message ID = 1969206303
ISAKMP (0): deleting spi 3349523324 message ID = 3177978048
return status is IKMP_NO_ERR_NO_TRANS
 
ISAKMP (0): beginning Quick Mode exchange, M-ID of 589268053:231f8455IPSEC(key_e
ngine): got a queue event...
IPSEC(spi_response): getting spi 0x1a1477ee(437549038) for SA
        from     xxx.xxx.xxx.xxx to    yyy.yyy.yyy.yyy for prot 3
 
crypto_isakmp_process_block: src xxx.xxx.xxx.xxx, dest yyy.yyy.yyy.yyy
ISAKMP (0): processing NOTIFY payload 18 protocol 3
        spi 437549038, message ID = 2273129329
ISAKMP (0): deleting spi 4000781338 message ID = 589268053
return status is IKMP_NO_ERR_NO_TRANS
IPSEC(key_engine): request timer fired: count = 1,
  (identity) local= yyy.yyy.yyy.yyy, remote= xxx.xxx.xxx.xxx,
    local_proxy= 172.21.1.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 172.25.9.0/255.255.255.0/0/0 (type=4)
 
ISAKMP (0): beginning Quick Mode exchange, M-ID of -264694791:f03913f9IPSEC(key_
engine): got a queue event...
IPSEC(spi_response): getting spi 0xf891318a(4170264970) for SA
        from     xxx.xxx.xxx.xxx to    yyy.yyy.yyy.yyy for prot 3
 
crypto_isakmp_process_block: src xxx.xxx.xxx.xxx, dest yyy.yyy.yyy.yyy
ISAKMP (0): processing NOTIFY payload 18 protocol 3
        spi 4170264970, message ID = 3260674997
ISAKMP (0): deleting spi 2318504440 message ID = 4030272505
return status is IKMP_NO_ERR_NO_TRANS      
 
Delta-PIX(config)# show isa sa
Total     : 3
Embryonic : 0
        dst            src         state     pending    created
     xxx.xxx.xxx.xxx    yyy.yyy.yyy.yyy    QM_IDLE        0           0

>What does this mean, "IKMP_NO_ERR_NO_TRANS"?

Nothing wrong with the tunnel, but nobody's transmitting anything down it.  VPNs need BOTH ends to be transmitting something before they are successfully established.
What do the NG error logs have to say ?  Is a tunnel established, or not ?
I suspect routing / NAT may be playing you up....

Embryonic : 0
        dst            src         state     pending    created
     xxx.xxx.xxx.xxx    yyy.yyy.yyy.yyy    QM_IDLE        0           0 <=== Tunnel is UP and waiting for traffic

It does appear to be a routing issue at this point....

Tim, can you peek at this one

https://www.experts-exchange.com/questions/21166583/Cisco-PIX-515e-VPN-to-non-cisco-peer.html#12300244

There may be a routing issue as well, but I still don't think the VPN tunnel is set up correctly. At one point there were 3 sa's for the same peer. One for the network and 2 more for separete hosts on my network that I was test pinging from. Is that normal? I cleared isa sa and now there is only 1 sa for the whole network.


   local  ident (addr/mask/prot/port): (172.21.1.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (172.25.9.0/255.255.255.0/0/0)
   current_peer: XXX.XXX.XXX.XXX
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
    #send errors 47, #recv errors 0

     local crypto endpt.: YYY.YYY.YYY.YYY, remote crypto endpt.: XXX.XXX.XXX.XXX
     path mtu 1500, ipsec overhead 0, media mtu 1500
     current outbound spi: 0

     inbound esp sas:


     inbound ah sas:


     inbound pcp sas:


     outbound esp sas:


     outbound ah sas:


     outbound pcp sas:



   local  ident (addr/mask/prot/port): (172.21.1.1/255.255.255.255/0/0)
   remote ident (addr/mask/prot/port): (172.25.9.11/255.255.255.255/0/0)
   current_peer: XXX.XXX.XXX.XXX
   dynamic allocated peer ip: 0.0.0.0

     PERMIT, flags={}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
    #pkts decaps: 6, #pkts decrypt: 6, #pkts verify 6
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: YYY.YYY.YYY.YYY, remote crypto endpt.: XXX.XXX.XXX.XXX
     path mtu 1500, ipsec overhead 56, media mtu 1500
     current outbound spi: 54b3a48e

     inbound esp sas:
      spi: 0x235a1ef9(593108729)
        transform: esp-3des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 11, crypto map: vpnclient
        sa timing: remaining key lifetime (k/sec): (4607999/22477)
        IV size: 8 bytes
        replay detection support: Y


     inbound ah sas:


     inbound pcp sas:


     outbound esp sas:
      spi: 0x54b3a48e(1421059214)
        transform: esp-3des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 12, crypto map: vpnclient
        sa timing: remaining key lifetime (k/sec): (4608000/22477)
        IV size: 8 bytes
        replay detection support: Y


     outbound ah sas:


     outbound pcp sas:



   local  ident (addr/mask/prot/port): (172.21.1.128/255.255.255.255/0/0)
   remote ident (addr/mask/prot/port): (172.25.9.11/255.255.255.255/0/0)
   current_peer: XXX.XXX.XXX.XXX
   dynamic allocated peer ip: 0.0.0.0

     PERMIT, flags={}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify 4
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: YYY.YYY.YYY.YYY, remote crypto endpt.: XXX.XXX.XXX.XXX
     path mtu 1500, ipsec overhead 56, media mtu 1500
     current outbound spi: 54b3a48d

     inbound esp sas:
      spi: 0x2b3e3f4c(725499724)
        transform: esp-3des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 9, crypto map: vpnclient
        sa timing: remaining key lifetime (k/sec): (4608000/23495)
        IV size: 8 bytes
        replay detection support: Y


     inbound ah sas:


     inbound pcp sas:


     outbound esp sas:
      spi: 0x54b3a48d(1421059213)
        transform: esp-3des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 10, crypto map: vpnclient
        sa timing: remaining key lifetime (k/sec): (4608000/23504)
        IV size: 8 bytes
        replay detection support: Y


     outbound ah sas:


     outbound pcp sas:


Why would there be 4 sa's when I show isa?

show isa sa
Total     : 3
Embryonic : 0
        dst                  src                 state     pending    created
     XXX.XXX.XXX.XXX    YYY.YYY.YYY.YYY    QM_IDLE        0           4


To test I am pinging 172.25.9.X from 172.21.1.X. I don't see how this wouldn't be routing correctly. My outside of the PIX is connected right to the Internet.

on my inside access list I have:
access-list 101 permit icmp any any

on my crypto map match access list I have:
access-list ddmi permit ip 172.21.1.0 255.255.255.0 172.25.9.0 255.255.255.0

I'm not NAting that traffic:
access-list 104 permit ip 172.21.1.0 255.255.255.0 172.25.9.0 255.255.255.0
nat (inside) 0 access-list 104


And the Crypto map is linked to the peer and the ACL
Crypto Map "vpnclient" 30 ipsec-isakmp
        Peer = XXX.XXX.XXX.XXX
        access-list ddmi permit ip 172.21.1.0 255.255.255.0 172.25.9.0 255.255.2
55.0 (hitcnt=73)
        Current peer: XXX.XXX.XXX.XXX
        Security association lifetime: 4608000 kilobytes/28800 seconds
        PFS (Y/N): N
        Transform sets={ vpnclient, }

When they ping from their side they get good IKE and encrypts to my LAN.  They do not get ping replies.

One way encrypts is DEFINITELY a routing problem.  By routing, I mean internal routing and not routing between the 2 external peers, as they can evidently see each other...
Routing may also get upset with NAT.  Double check Check Point's address translation rules aren't interfering - there's usually a global hide rule in there somewhere, but we don't want that to be invoked.

Actually the problem was on the CheckPoint side. They didn't have "allow key exchange on subnets" checked in the policy for this VPN connection. So we weren't completing phase 2 of the VPN setup.

Cool.... don't forget to close this one out.
The 'allow key exchange for subnets' is pretty much common knowledge, and is referenced everywhere, including the link that lrmoore posted up, and you did say you'd read it !  :0)