S2S IKEv2 VTI Tunnel from ASA to Cradlepoint IRB900

[cco@leferguson.com]

I believe I have something silly that does not match, but two days of increasingly random experimentation has not yielded results.

I have an ASA5516-X at 9.14.3.18 connecting to a cradlepoint modem/router, with the goal to connect IP's on the cradlepoint of 192.168.123.64/29 to IP's on the ASA inside network of 10.173.1.0/24. 

I have control over both sides of the connection.  Because this is a live government site and live production environment I am reluctant to post full configs and debug, but am hoping someone can give some pointers from what I have.   Here is a pretty complete ASA config: 

crypto ikev2 policy 78
encryption aes-256
integrity sha256
group 14
lifetime seconds 3600

crypto ikev2 enable outside

group-policy STRATUS-TUNNELS-GROUP-POLICY internal
group-policy STRATUS-TUNNELS-GROUP-POLICY attributes
vpn-tunnel-protocol ikev2

tunnel-group CRADLEIP type ipsec-l2l
tunnel-group CRADLEIP general-attributes
default-group-policy STRATUS-TUNNELS-GROUP-POLICY
tunnel-group CRADLEIP ipsec-attributes
ikev2 remote-authentication pre-shared-key REDACTED
ikev2 local-authentication pre-shared-key REDACTED

crypto ipsec ikev2 ipsec-proposal STRATUS-IPSEC-PROP
protocol esp encryption aes-256
protocol esp integrity sha-256

crypto ipsec profile STRATUS-TUN-PROFILE
set ikev2 ipsec-proposal STRATUS-IPSEC-PROP
set security-association lifetime kilobytes unlimited
set security-association lifetime seconds 3600

interface Tunnel78
description Tunnel to stratus
nameif vti78
ip address 172.18.2.2 255.255.255.252
tunnel source interface outside
tunnel destination CRADLEIP
tunnel mode ipsec ipv4
tunnel protection ipsec profile STRATUS-TUN-PROFILE

route vti78 192.168.123.64 255.255.255.248 172.18.2.1 1

The cradlepoint config, as best I can tell mirrors that (opposite local networks of course).  At present I set the cradlepoint to only respond, not initiate, just so I can not get intermixed debugs. 

I get through the PSK authentication just fine, but it dies shortly afterwards.  I THINK that the first errors appear here: 

IKEv2-PLAT-4: CONNECTION STATUS: REGISTERED... peer: 107.89.22.252:500, phase1_id: 107.89.22.252
IKEv2-PROTO-4: (721): Initializing DPD, configured for 10 seconds
IKEv2-PLAT-4: mib_index set to: 501
IKEv2-PROTO-7: (721): SM Trace-> SA: I_SPI=0EFB8433AF0A273E R_SPI=C3F186DB7F0678B2 (I) MsgID = 00000001 CurState: AUTH_DONE Event: EV_RECD_REGISTER_SESSION_RESP
IKEv2-PROTO-7: (721): SM Trace-> SA: I_SPI=0EFB8433AF0A273E R_SPI=C3F186DB7F0678B2 (I) MsgID = 00000001 CurState: AUTH_DONE Event: EV_GEN_LOAD_IPSEC
IKEv2-PROTO-4: (721): Load IPSEC key material
IKEv2-PLAT-4: Crypto Map: no match on map __vti-crypto-map-4-0-78 seq 65280
IKEv2-PROTO-2: (721): Ipsec policy not found
IKEv2-PROTO-7: (721): SM Trace-> SA: I_SPI=0EFB8433AF0A273E R_SPI=C3F186DB7F0678B2 (I) MsgID = 00000001 CurState: READY Event: EV_DEL_SA

 Shortly afterwards it sends a delete.  

Since it's a VTI tunnel there is no explicit crypto map exactly (at least as I understand it), but i THINK I have all the subnets matching on both sides (flipped obviously).   Here is a packet BEFORE the attached error from the debug logs: 

IKEv2-PLAT-4: (721): Decrypt success status returned via ipc 1
(721): REAL Decrypted packet:(721): Data: 144 bytes
 IDr  Next payload: AUTH, reserved: 0x0, length: 12
    Id type: IPv4 address, Reserved: 0x0 0x0

     6b 59 16 fc
 AUTH  Next payload: SA, reserved: 0x0, length: 40
    Auth method PSK, reserved: 0x0, reserved 0x0
Auth data: 32 bytes
 SA  Next payload: TSi, reserved: 0x0, length: 44
  last proposal: 0x0, reserved: 0x0, length: 40
  Proposal: 1, Protocol id: ESP, SPI size: 4, #trans: 3    last transform: 0x3, reserved: 0x0: length: 12
    type: 1, reserved: 0x0, id: AES-CBC
    last transform: 0x3, reserved: 0x0: length: 8
    type: 3, reserved: 0x0, id: SHA256
    last transform: 0x0, reserved: 0x0: length: 8
    type: 5, reserved: 0x0, id: Don't use ESN
 TSi  Next payload: TSr, reserved: 0x0, length: 24
    Num of TSs: 1, reserved 0x0, reserved 0x0
    TS type: TS_IPV4_ADDR_RANGE, proto id: 17, length: 16
    start port: 0, end port: 65535
    start addr: 10.173.1.0, end addr: 10.173.1.255
 TSr  Next payload: NONE, reserved: 0x0, length: 24
    Num of TSs: 1, reserved 0x0, reserved 0x0
    TS type: TS_IPV4_ADDR_RANGE, proto id: 17, length: 16
    start port: 0, end port: 65535
    start addr: 192.168.123.64, end addr: 192.168.123.71

If I am reading it right that's from the Cradlepoint and includes its range the 10.173.1.0 <==> 192.168.123.64; I'm unclear on whether it is in the right order, but certainly everything on Cradlepoint shows "Local networks" on the Cradlepoint of 192.168.123.64/29 and "Remote networks" as 10.173.1.0/24, which looks right.

Also, the generated name of the cryptomap is referred to once in the debugs higher up still and just shows this (which is the right tunnel group).  I'm not clear if the "Prot=0" is right nor the "xport=1", but it finds the tunnel group; at least, and proceeds to authenticate. 

Nov 17 15:10:04 [IKE COMMON DEBUG]Tunnel Manager dispatching a KEY_ACQUIRE message to IKEv2.  Map Tag = __vti-crypto-map-4-0-78.  Map Sequence Number = 65280.
IKEv2-PLAT-4: Received PFKEY Acquire SA for SPI 0x0, error FALSE
IPSEC(crypto_map_check)-3: Looking for crypto map matching 5-tuple: Prot=0, saddr=ASAIP, sport=1, daddr=CRADLEIP, dport=1
IKEv2-PLAT-7: INVALID PSH HANDLE
IKEv2-PLAT-7: INVALID PSH HANDLE
IKEv2-PLAT-4: attempting to find tunnel group for IP: CRADLEIP
IKEv2-PLAT-4: mapped to tunnel group CRADLEIP using peer IP
IKEv2-PLAT-7: INVALID PSH HANDLE
IKEv2-PLAT-7: INVALID PSH HANDLE
IKEv2-PLAT-7: INVALID PSH HANDLE
IKEv2-PLAT-4: my_auth_method = 2
IKEv2-PLAT-4: supported_peers_auth_method = 2
IKEv2-PLAT-4: P1 ID = 0
IKEv2-PLAT-4: Translating IKE_ID_AUTO to = 255
IKEv2-PLAT-7: INVALID PSH HANDLE
IPSEC: Received a PFKey message from IKE
IPSEC: Parsing PFKey GETSPI message
IPSEC: Creating IPsec SA
IPSEC: Getting the inbound SPI

I'm using the same encryption and hash in Phase 1 as Phase 2, and it made it through Phase 1 so I hope those are OK.  I've tried with and without PFS enabled (using group 14 on both sides). 

Can anyone tell me what sort of thing to look for?  I'm buried in debug logs (which are just too much to try to redact, probably pushing the limit by leaving internal IP's but we plan to change those before these devices go into production, those are how they came from the factory) by running out of things to try. 

Linwood

[Rob Ingram]

cco@leferguson.comWhen using a route based VPN (VTI) you don't have create an ACL to match the subnets on both sides (flipped/mirrored) - you create a tunnel interface and route traffic via static/dynamic routing protocol to the tunnel interface. You need to use VTI's and routes on both ends.

It certainly looks like you've configured the ASA correctly with a VTI and a static route via the tunnel interface, but what about the peer device (cradlepoint)? That also needs a VTI and static route. From the logs this "start addr: 10.173.1.0, end addr: 10.173.1.255" implies the cradlepoint is configured using a policy based VPN, not a route based VPN (VTI).

[cco@leferguson.com]

yes, the Cradlepoint has an explicit type of VTI tunnels, and when selected it requires entry of the local IP information described as "Local networks" with context help describing it as local networks the tunnel is connected to, and also "remote networks" and "Static routes" (these are on the tunnel setup pages), and I have filled those in accordingly with the ASA side subnet.  Interestingly the "Static routes" there is just the subnet, not the route, but I also (just in case, and tried it with and without) put in a separate static route explicitly listing the ASA tunnel interface IP. 

Just to be sure (and a combination I had not tried) I removed the remote networks from the tunnel setup leaving it only in the static route (on the cradlepoint).  This time The section with addresses is different, the "TSi" section shows just the ASA outside address.  Which I suspect is wrong?  The "TSr" still shows the Cradlepoint side LAN address range.  However from that point on it looks identical - the PSK authentication works, and shortly afterwards it gievs a "Ipsec policy not found" after the "no match on map" as above. 

After this note going to try to redact and past in the screen shots, if Cisco will let me.... 

[cco@leferguson.com]

Screen shots from cradlepoint: 

[cco@leferguson.com]

I also just went in and removed the local networks shown in the screen shots and tried again, now the TSi and TSr are just the outside addresses of each device, but it still gives the same no-match and ipsec policy not found.

There is a static route on both to the other's local addresses.

[MHM Cisco World]

are you config any other IPSec MAP under the tunnel source interface ??

[cco@leferguson.com]

---

@MHM Cisco World wrote:

are you config any other IPSec MAP under the tunnel source interface ??

---

This ASA does have AnyConnect configured on the outside interface, but does not have any other tunnels of any type configured.

[MHM Cisco World]

I think 
unclick the separate Child SA, since we use only VTI not use multi crypto map ACL that need each Child,

[cco@leferguson.com]

It was a good thought as I had turned that on previously experimenting and forgot about it, but turning it off had no apparent impact, still get that Ipsec policy not found". 

I figured out how to pull logs from the other side, and learned even less there.  It appears happy until it gets the first packet after authentication and that's a delete request from the ASA.  So it does not seem unhappy up to that point, and the delete does not have any useful information in it that makes it to the log. 

[MHM Cisco World]

are you unclick it with select the initiate mode <<always ON>>
after you you do change clear crypto in ASA ipsec sa and isakmp 

[cco@leferguson.com]

No apparent change in the ASA initiated ones, but now from the Cradle initiated ones in the Cradle log I have a possible clue (this is read bottom up in terms of chronology)

2022-11-18 14:34:41|    INFO|       ipsec|12[IKE] closing IKE_SA due CHILD_SA setup failure
2022-11-18 14:34:41|    INFO|       ipsec|12[IKE] received TS_UNACCEPTABLE notify, no CHILD_SA built
2022-11-18 14:34:41|    INFO|       ipsec|12[IKE] maximum IKE_SA lifetime 3437s
2022-11-18 14:34:41|    INFO|       ipsec|12[IKE] scheduling rekeying in 3077s
2022-11-18 14:34:41|    INFO|       ipsec|12[IKE] IKE_SA 00000001-3594-3c21-946f-db0eb79a60ae[3926] state change: CONNECTING => ESTABLISHED
2022-11-18 14:34:41|    INFO|       ipsec|12[IKE] IKE_SA 00000001-3594-3c21-946f-db0eb79a60ae[3926] established between CRADLEIP[CRADLEIP]...ASAIP[ASAIP]
2022-11-18 14:34:41|    INFO|       ipsec|12[IKE] authentication of 'ASAIP' with pre-shared key successful
2022-11-18 14:34:41|    INFO|       ipsec|12[ENC] parsed IKE_AUTH response 1 [ V IDr AUTH N(TS_UNACCEPT) ]
2022-11-18 14:34:41|    INFO|       ipsec|12[NET] received packet: from ASAIP[500] to CRADLEIP[500] (160 bytes)
2022-11-18 14:34:41|    INFO|       ipsec|11[NET] sending packet: from CRADLEIP[500] to ASAIP[500] (256 bytes)
2022-11-18 14:34:41|    INFO|       ipsec|11[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
2022-11-18 14:34:41|    INFO|       ipsec|11[IKE] establishing CHILD_SA 00000001-3594-3c21-946f-db0eb79a60ae{4314}
2022-11-18 14:34:41|    INFO|       ipsec|11[IKE] successfully created shared key MAC

Notice the "TS_UNACCEPTABLE", it would seem like the ASA is still sending a rejection of some sort.   I have yet to see a clear indication that the Cradlepoint is unhappy, it is just the ASA that kills it regardless of who initiates. 

[cco@leferguson.com · Accepted solution]

Problem solved.  It is the VTI Traffic Selectors on the first screen.  That SOUNDS like (if you read their documentation) it controls split vs all-tunnel, but it apparently sends the subnets to the ASA and the ASA doesn't expect it.  Turn those off and it's up and working.  Answer thanks to Cradlepoint support, which I was working in parallel.