IKEv2 - Is the tunnel up or not? Tunnel Manager has failed to establish an L2L SA

[Greg Focaccio]

Hi All,

Having trouble getting two way ESP IPSec IKEv2 L2L tunnel between 5506 and SRX 4200

I have the configs from both sides and everything appears to match.

It appears I have a functional tunnel based on the output of "sh crypto ikev2 sa" and "sh crypto ipsec sa":

hostname# sh crypto isakmp sa

There are no IKEv1 SAs

IKEv2 SAs:

Session-id:30, Status:UP-ACTIVE, IKE count:1, CHILD count:2

Tunnel-id Local Remote Status Role
511190113 ---/500 ---/500 READY RESPONDER
Encr: AES-CBC, keysize: 256, Hash: SHA256, DH Grp:19, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/1668 sec
Child sa: local selector --- /0 - ---/65535
remote selector ---/0 - ---/65535
ESP spi in/out: 0x3d94277d/0x53f01c76
Child sa: local selector ---/0 - ---/65535
remote selector ---/0 - ---/65535
ESP spi in/out: 0xf28792b2/0x386fbdd5
hostname#
hostname#
hostname# sh crypto ipsec sa
interface: outside
Crypto map tag: CRYPTO-MAP, seq num: 100, local addr: A.B.C.D

access-list NEW-VPN-TRAFFIC extended permit ip local remote
local ident (addr/mask/prot/port): (---/255.255.255.248/0/0)
remote ident (addr/mask/prot/port): (---/255.255.255.0/0/0)
current_peer: E.F.G.H

#pkts encaps: 336, #pkts encrypt: 336, #pkts digest: 336
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 336, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0

There are no decaps. 

If the tunnel is up w/ one-way traffic, then what is the Tunnel Manager message about failed to establish L2L SA in the log seen below: 

Jun 08 2018 04:07:46: %ASA-4-752012: IKEv2 was unsuccessful at setting up a tunnel. Map Tag = CRYPTO-MAP. Map Sequence Number = 100.
Jun 08 2018 04:07:46: %ASA-3-752015: Tunnel Manager has failed to establish an L2L SA. All configured IKE versions failed to establish the tunnel. Map Tag= CRYPTO-MAP. Map Sequence Number = 100.
Jun 08 2018 04:07:46: %ASA-5-750006: Local:A.B.C.D:500 Remote:E.F.G.H:500 Username:E.F.G.H IKEv2 SA UP. Reason: New Connection Established

Since there is a IKEv2 SA UP log message - AFTER - the "failed to establish an  L2L SA", can the faile to establish message be ignored or is it valid.

Are there any peculiarities to IKEv2 between ASA and JUNOS SRX ?  I set up a test IKEv2 between two ASA 5506 and had no issue.

Thanks,

Greg

[Greg Focaccio]

If it wasn't for the "failed to establish" entry in the log, then one would think that there is a routing or no-nat issue on the other side, right?   

The other side is using a "templatized" config that they have working to other locations, so that seems to weigh against it being a nat issue on the far side.  There could still be an internal routing issue preventing interesting subnets on farside from getting to the inside of the farside firewall.

The farside is getting this UP for IKEv2 SA

hostname> show security ike security-associations | grep A.B.C.D

1477708 UP     c132b0d60a96a816  fe06d7af7bc1c0e7  IKEv2          A.B.C.D

I've requested the farside run this junos command on their srx as an equivalent to "sh crypto ipsec sa" to see if there is any traffic policy matched - since the far side is doing policy VPN.

show security flow session source-prefix [source subnet on "remote side"] destination-prefix [interesting subnet on "local (my) side"]

[Greg Focaccio]

I am going to obtain an SRX 240 running JUNOS OS to get to the bottom of this...

Will update when I get the data.

[Greg Focaccio · Accepted solution]

More to follow [complete ASA and JUNOS configs], but with the SRX in hand, I was able to run tests.  I was finally able get an IKEv2 IPSec tunnel up between an ASA 5506 running 9.8(1) and an srx240b running JUNOS 12.1X46-D76 [some JUNOS config help from Jimmy]

The problem seems to have been the secure hash algorithm SHA. 

Using SHA 256 did not work, switching to SHA / SHA-1 makes it work.

Had a clue from this post by Jonathan:

http://priority-zero.blogspot.com/2013/10/cisco-asa-to-juniper-ssg-ikev2-ipsec.html

Whew!   Maybe someone has more insight on this.