IPsec/IKEv2 error

[fcardoso]

Hello everyone, I have an ipsec/ikev2 Lan-to-Lan VPN working between an ASA and router A (Cisco), with this router behind a public router that is performing NAT, However, it keeps giving the following errors in the ASA side (i do not have information off router A, it is a client side):

30 in 30 seconds:

Local:203.0.113.45:4500 Remote:185.60.218.35:4500 Username:185.60.218.35 IKEv2 Negotiation aborted due to ERROR: There was no IPSEC policy found for received TS

Local:203.0.113.45:4500 Remote:185.60.218.35:4500 Username:185.60.218.35 IKEv2 Tunnel rejected: Crypto Map Policy not found for remote traffic selector 192.168.200.0/192.168.200.255/0/65535/0 local traffic selector 10.230.184.0/10.230.184.255/0/65535/0!

55 in 55 minutes:

IPSEC _ An inbound LAN-to-lAN SA (SPI - 0x12CPCSEO) between 185.60.218.35 and 203.0.113.45 (user- 185.60.218.35) has been deleted.
PSEC - An outbourd LAN-to-LAN SA (SPI- 0x69660748) between 203.0.113.45 and 185.60.218.35 (user- 185.60.218.35) has beer deleted
IPSEC - An inbound LAN-to-LAN SA (SPI- OKFBAE7961) between 203.0.113.45 and 185.60.218.35 (user_ 185.60.218.35) has been created
IPSEC - An outbound laN-to-LAN SA (SPI" 0¥72053486) between 203.0.113.45 and 185.60.218.35 (user- 185.60.218.35) has been created

PS: the router A have a SLA to keep the tunnel up ...

Despite no complaints from the client, the tunnel isn't functioning normally as can be seen in the logs. Any ideas?

Best regards

Fernando

[MHM Cisco World]

Show crypto ikev2 sa

Share this 

MHM

[fcardoso]

Hi MHM, here is the result:

IKEv2 SAs:

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

Tunnel-id Local Remote Status Role
3070623963 203.0.113.45/4500 185.60.218.35/4500 READY INITIATOR
Encr: AES-CBC, keysize: 256, Hash: SHA512, DH Grp:21, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/10083 sec
Child sa: local selector 192.168.200.25/0 - 192.168.200.25/65535
remote selector 10.230.184.1/0 - 10.230.184.1/65535
ESP spi in/out: 0x1277cd1e/0xc82fe562

-- Perhaps the router was supposed to be the initiator !!!!!

Fernando

[MHM Cisco World]

Yes it can be but you mention IP SLA 
where you use it ? in this router (the initiator)?

MHM  

[fcardoso]

I'm not familiar with the client's router configuration in detail, I just know that they have a configuration on the router (SLA), which is part of the traffic of interest that allows the tunnel to stay active....

Without this configuration, after some time, the tunnel goes down and never comes back up....

Also, I know that the client has configured the traffic of interest with /24 and not with /32 as I have configured on the ASA. Could this be a problem?

PS: I tested in lab with deferent mask off interesting traffic in booth sides  and it worked well.......

Thanks for the help

Fernando

[MHM Cisco World]

Sorry late reply I was busy 

Now router send IP SLA but the ASA is initiator 

The initiator is the peer can build Child SA' here router with IP SLA not solution'

To make it work 

Clear crypto ipsec  peer <router> 

Make sure the asa is responder not initiator and config router to send IP SLA to make tunnel UP and child SA is generate.

Note:- also you can use IP SLA LAN-to-LAN from ASA side to make ASA build Child SA

MHM

[MHM Cisco World]

NOTE NOTE

@fcardoso  

You mention using different mask in lab and work!

This can be tricky' did you add more than one vpn in lab

I think it work well in lab since you have one vpn 

When you add other vpn then you will start to see conflict and SPI not correct.

Why?

If we have for example vpn1 use host 192.168.1.1/32 to 172.16.0.0/24

And vpn2 192.168.1.2/32 to 172.16.0.0/24

But instead in peer  of using/32 ypu use /24 for one vpn

This make peer send traffic for both 192..../32 toward one vpn

The receiver see different spi from what it use and drop packet.

Check also this point with point of initiator 

MHM

[fcardoso]

You are absolutely correct. That is to say, in the lab, I only tested with one tunnel... It makes perfect sense, essentially we will have overlapping traffic of interest for different VPNs... Next week, I will get in touch with the client to jointly adjust the proxy ACLs....

tanks for the help

Fernando

[MHM Cisco World]

I wish you goodluck in your task 

Thanks and Have a nice day 

MHM

[fcardoso]

I restarted the tunnel using "Clear crypto ipsec peer <router>," but the initiator always stays on the ASA side... Furthermore, I stopped all traffic of interest originating from the inside of the ASA, but the tunnel never comes back up. In other words, only after restarting the traffic of interest from the inside of the ASA does the tunnel come back up.

I wasn't expecting this behavior; I thought it would be sufficient for the traffic originating from the IP SLA of the client router to cause Phase 1 to go up and then Phase 2 to also come up through NAT-T... considering that the client router is behind an internet router that is performing NAT overload to the internet... Does that make sense?

[MHM Cisco World · Accepted solution]

Let postponed this to next week when you check the client ACL

Thanks 

MHM

[Marius Gunnerud · Accepted solution]

The issue is with the crypto ACL that is configured.  There is a mismatch either on your side or on the remote side and this can be identified with the first two logs that you provided:

Local:203.0.113.45:4500 Remote:185.60.218.35:4500 Username:185.60.218.35 IKEv2 Negotiation aborted due to ERROR: There was no IPSEC policy found for received TS

Local:203.0.113.45:4500 Remote:185.60.218.35:4500 Username:185.60.218.35 IKEv2 Tunnel rejected: Crypto Map Policy not found for remote traffic selector 192.168.200.0/192.168.200.255/0/65535/0 local traffic selector 10.230.184.0/10.230.184.255/0/65535/0!

TS references Traffic Selector. 

So you need to engage the remote side administrators and compare the configurations of the crypto ACL.

[fcardoso]

"You are correct, there are different crypto ACLs on both sides... Next week, I will speak with the client to align the ACLs and verify if the alarms disappear..."

[Marius Gunnerud]

Also, I know that the client has configured the traffic of interest with /24 and not with /32 as I have configured on the ASA. Could this be a problem?

This can definitely cause issues if you have configured /32 for your local crypto domain and the remote side has /24 for your side.  that means that only the single IP you have configure will be reachable over the VPN, so if the remote side tries to connect to a different IP traffic will be dropped. You, and the remote administrator, need to agree on what you want to send over the VPN and then correct the configuration accordingly.

Alternatively you can migrate to route-based VPN and this will not be an issue any more.

[fcardoso]

"The traffic of interest between us and the client is only between a server and a client machine, meaning /32 is sufficient. However, the tunnel only comes up when the client changes to a proxy ACL for the /24 network because they have an IP SLA configured on the router to keep the tunnel up, and the source IP of this SLA is another IP..."

"But next week I will clarify with the client... Thank you very much for your help."