L2L IKEV2 IPSEC TUNNEL - ESTABLISHED SAs -

[Prime56]

Hi all,

I have a SA established and am trying to ping the remote tunnel interface. I have my site set to 172.16.118.1 and the remote side set to 118.2.

After attempting to ping, I issue show crypto ipsec sa and I see this:

#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

What would be causing this? I've enabled NAT traversal, management-access inside, any other suggestions?

I'll be happy to provide any output needed.

[MHM Cisco World]

Can you share the config of ikev2 tunnel?

[Prime56]

Here is the tunnel interface on my side:

tunnel-group 216.1xx.xx.xx type ipsec-l2l
tunnel-group 216.1xx.xx.xx general-attributes
default-group-policy IKEV2
tunnel-group 216.1xx.xx.xx ipsec-attributes
ikev1 pre-shared-key *****
ikev2 remote-authentication pre-shared-key *****
ikev2 local-authentication pre-shared-key *****

interface Tunnel1
nameif VTI-CLN-COLO
ip address 172.16.118.1 255.255.255.252
tunnel source interface outside
tunnel destination 216.1xx.xx.xx
tunnel mode ipsec ipv4
tunnel protection ipsec profile IKEV2

This remote side is via an ATT WAN link. I've heard ATT can have problems with IPSEC traffic even though the tunnel forms? Possibility? 

[MHM Cisco World]

Config the 

Since the encrypt is ok and decrypt then the other side not use the tunnel to send traffic to your side.

we can solve this by running any protocol between the both side using tunnel.

[Prime56]

Could you elaborate?  I've already tried to send packets over the link via packet tracer

[MHM Cisco World]

https://www.cisco.com/c/en/us/support/docs/security/adaptive-security-appliance-asa-software/214109-configure-asa-ipsec-vti-connection-to-az.html

This is vti so it route based s2s ipsec,

the traffic will use the tunnel when the next-hop of other side LAN is other peer tunnel ip.

you can do this by 

1- config static route in each peer 

2-config any protocol and in example above bgp used to advertise the Your side LAN to other side.

[Aref Alsouqi]

Having encaps but not decaps would mean your device is encrypting the traffic correctly, but it is not receiving back the return traffic inside the tunnel, or not receiving back at all. This most likely would be something wrong on the remote side config. It could be a missing route to send the traffic into the tunnel, or it could also be related to an ACL that is denying the traffic from the remote site sources to your site.

I would start troubleshooting this with some packet capture, if that doesn't help much, I would enable the crypto debugs.

[Prime56]

This is the input from the datacenter to my problematic connection. Ping from inside to other side of tunnel interface. Does anything look wrong here?

packet-tracer input inside icmp 192.168.208.1 8 0 172.16.118.1

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 172.16.118.1 using egress ifc  VTI-COLO-CLN

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group Blocked_IPs in interface inside
access-list Blocked_IPs extended permit ip any any 
Additional Information:

Phase: 3
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 4      
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
class-map inspection_default
 match default-inspection-traffic
policy-map global_policy
 class inspection_default
  inspect icmp 
service-policy global_policy global
Additional Information:

Phase: 6
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:       
Additional Information:

Phase: 7
Type: FLOW-EXPORT
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

Phase: 10     
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 11
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 12
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:
New flow created with id 1346323634, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: VTI-COLO-CLN
output-status: up
output-line-status: up
Action: allow

[Prime56]

I have a default route to send everything not configured out the WAN interface....this should be enough right?

[Aref Alsouqi]

No that wouldn't be enough, you still need to add the static route on the remote site to send the VPN traffic across the tunnel.

[Prime56]

Can we dial it back? My issue isn't sending the LAN traffic over the VPN, its pinging the directly connected VTI interface. I would like that to be successful before adding routes to route the traffic.

[Prime56]

This is the only debug output I get on the datacenter for debug ikev2.....is this problematic? I don't really know what I'm looking at

IKEv2 Recv RAW packet dump
5c 22 33 82 41 a8 a7 4e 3a cf 75 cb 34 d3 e5 20    |  \"3.A..N:.u.4.. 
2e 20 25 28 00 00 00 83 00 00 00 50 00 00 00 34    |  . %(.......P...4
a7 f9 ab c0 90 f2 e8 21 df 76 97 6a e4 72 88 21    |  .......!.v.j.r.!
6c ee c3 66 7e f6 8c 2c 3b d1 c9 e9 0e cc e6 a5    |  l..f~..,;.......
51 ab f5 9a 8d 98 c4 47 9c e0 42 6c 9e 92 f4 b3    |  Q......G..Bl....
(335):  
IKEv2-PROTO-2: (335): Received Packet [From 12.3.193.18:500/To 216.117.84.36:500/VRF i0:f0] 
(335): Initiator SPI : 5C22338241A8A74E - Responder SPI : 3ACF75CB34D3E520 Message id: 131
(335): IKEv2 INFORMATIONAL Exchange RESPONSEIKEv2-PROTO-3: (335): Next payload: ENCR, version: 2.0 (335): Exchange type: INFORMATIONAL, flags: INITIATOR MSG-RESPONSE (335): Message id: 131, length: 80(335):  
Payload contents: 
(335):  
(335): Decrypted packet:(335): Data: 80 bytes
IKEv2-PLAT-2: (335): Decrypt success status returned via ipc 1
(335): REAL Decrypted packet:(335): Data: 0 bytes
IKEv2-PROTO-5: (335): SM Trace-> SA: I_SPI=5C22338241A8A74E R_SPI=3ACF75CB34D3E520 (I) MsgID = 00000083 CurState: INFO_I_WAIT Event: EV_RECV_INFO_ACK
IKEv2-PROTO-2: (335): Processing ACK to informational exchange
IKEv2-PROTO-5: (335): SM Trace-> SA: I_SPI=5C22338241A8A74E R_SPI=3ACF75CB34D3E520 (I) MsgID = 00000083 CurState: INFO_I_WAIT Event: EV_CHK_INFO_TYPE
IKEv2-PROTO-5: (335): SM Trace-> SA: I_SPI=5C22338241A8A74E R_SPI=3ACF75CB34D3E520 (I) MsgID = 00000083 CurState: EXIT Event: EV_CHK_PENDING
IKEv2-PROTO-5: (335): Processed response with message id 131, Requests can be sent from range 132 to 132
IKEv2-PROTO-5: (335): SM Trace-> SA: I_SPI=5C22338241A8A74E R_SPI=3ACF75CB34D3E520 (I) MsgID = 00000083 CurState: EXIT Event: EV_NO_EVENT
IKEv2-PROTO-5: (335): SM Trace-> SA: I_SPI=5C22338241A8A74E R_SPI=3ACF75CB34D3E520 (I) MsgID = 00000083 CurState: EXIT Event: EV_FREE_NEG
IKEv2-PROTO-5: (335): Deleting negotiation context for my message ID: 0x83

[MHM Cisco World]

All not config toward wan interface ? Can you more elaborate?

[Prime56]

I have a default route 0.0.0.0/0 out the wan gateway

[MHM Cisco World]

LAN1-ASA1"tunnel 1"--Internet--ASA2"tunnel 2"-LAN2

route LAN2 tunnel 1 <- in ASA1

router LAN1 tunnel 2 <- in ASA2 

this is VTI not IPSec S2S so the intent traffic need route not match IPSec ACL.

Note:-please dont delete the config of 
route 0.0.0.0/0 WAN in both side, this is use for tunnel destination.