IKEv2 Tunnel rejected: Crypto Map Policy not found - Azure VPN

[tcmckay]

I have a S2S VPN tunnel to Azure from my 2130 FTD that works, passes traffic and is fairly stable, however, I have recently started to see the above message on the FTP logs. All of the networks identified in the error can access Azure networks so I am confused as to why I would get the error. Any ideas on this are welcome.

Error Message

Local:xx.xx.xx.xx:500 Remote:xx.xx.xx.xx:500 Username:52.237.12.27 IKEv2 Tunnel rejected: Crypto Map Policy not found for remote traffic selector 10.9.2.0/10.9.2.255/0/65535/0 local traffic selector 10.12.0.0/10.12.255.255/0/65535/0!

show crypto ikev2 sa

IKEv2 SAs:

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

Tunnel-id Local Remote Status Role
597042631 XX.XX.XX.XX/500 XX.XX.XX.XX/500 STANDBY RESPONDER
Encr: AES-CBC, keysize: 256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/2487 sec
Child sa: local selector 10.10.254.0/0 - 10.10.254.255/65535
remote selector 10.9.0.0/0 - 10.9.255.255/65535
ESP spi in/out: 0xba63eabb/0x3d9d2ee8
Child sa: local selector 10.12.12.0/0 - 10.12.12.255/65535
remote selector 10.9.0.0/0 - 10.9.255.255/65535
ESP spi in/out: 0xd9331d5d/0x9866ec8
Child sa: local selector 10.8.8.0/0 - 10.8.8.255/65535
remote selector 10.9.0.0/0 - 10.9.255.255/65535
ESP spi in/out: 0xd4bf0bda/0x60d5df10
Child sa: local selector 10.10.1.0/0 - 10.10.1.255/65535
remote selector 10.9.2.0/0 - 10.9.2.255/65535
ESP spi in/out: 0x9d301e3e/0x1e55773c
Child sa: local selector 10.10.1.0/0 - 10.10.1.255/65535
remote selector 10.9.0.0/0 - 10.9.1.255/65535
ESP spi in/out: 0xcd4fbf7d/0xb628ed34

[Marvin Rhoads]

It appears the Azure end is putting traffic destined for 10.12.0.0/16 into the tunnel but your end doesn't have that in the ACL referred to by the crypto map.

[tcmckay]

In Azure I have 10.10.0.0/16, 10.12.0.0/16 and 10.8.0.0/16 as remote address spaces. These address spaces are part of the tunnel but I am more specific on the FTD side. I have only allowed 10.10.1.X/24, 10.10.254.X/24, 10.8.8.X/24 and 10.12.12.X/24. Do I have to be specific on both ends? It looks like only some of the networks have issues

[Marvin Rhoads]

As I understand it, I believe it can be affected by which end initiates the first flow for a given SA. Say you initiate asking for a /24 and Azure has a /16. Since it has a superset all is good. If it initiates thinking you will allow a /16 but you only have a /24 defined then that will be a problem. A best practice is to have both ends mirror each other exactly as far as the allowed networks.

[tcmckay]

I added the /24 address space on the Azure side for the 10.12.X.X addresses. The curious thing is in Azure I use /16 for 3 address spaces but on the FTD I use /24 for 6 specific networks. Of the 6 there are 2 in the 10.12.X.X/16 space and they are the only one erroring out. The other 4 ip spaces are fine. Now this could be due to traffic not going to them at this time same maybe some more testing is in order. Also I have full traffic flow to and from all 6 spaces.

[tcmckay · Accepted solution]

Looks like those changes made the difference. I set the space on both ends to be /16.