cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2169
Views
0
Helpful
5
Replies

%CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet. (ip) vrf/dest_addr= /x.x.x.x, src_addr= x.x.x.x, prot= 47

Zeeshan Anwar
Level 1
Level 1

Hi ,

I am want to crerate a GREover IPsec Tunnel between Cisco ASR 1002 and cisco 3900 i am getting the below error.

%CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet. (ip) vrf/dest_addr= /x.x.x.x, src_addr= x.x.x.x, prot= 47

I have attached the configuration file as well currently working on tunnel 117.

Site A already have some tunnels up and running but only tunnel 117 is not working which i created now on ASR 1002.

CAN ANYONE LET ME KNOW WHAT I AM FACING AN ISSUE.

5 Replies 5

Richard Burts
Hall of Fame
Hall of Fame

The first issue that I note is that you have applied the crypto map on the tunnel interface as well as on the physical interface. While there are perhaps still some examples that show this they are based on the operation of quite old IOS versions. The code that you are now running expects the crypto map to be applied only on the physical interface. I suggest that you remove the crypto map from the tunnel interfaces. Try that and let us know if the behavior changes.

HTH

Rick

HTH

Rick

Hi, Richard

Can i apply crypto map on a Loopback interface on IOS XE 3.16. (isr4451)?

I have not applied a crypto map to a loopback interface and so can not speak from experience about this. From a syntax perspective I would expect that the commands to apply the crypto map to a loopback interface would be accepted. I am not clear why you would want to do this and not sure how it would work.

In my original response I talked about applying the crypto map on tunnel interface and on physical interface because that is what was being done in the original post. Perhaps it would be beneficial to refine my explanation and talk about applying the crypto map on the exit interface (and take "physical" out of consideration). It is not very important whether the interface is physical or virtual. What is important is that it is the interface through which the packet is forwarded out of the device. So I would expect that the crypto map could be applied successfully on a physical interface, on an SVI, or on a loopback interface, as long as that interface is the interface through which the encrypted packets will be sent.

Remember that what is happening is that IOS examines packets as they are sent out the interface and if a crypto map is applied to that interface then IOS evaluates whether the packet matches the conditions of the crypto map and determines whether the packet should be encrypted or not.

So is your loopback interface the exit interface for encrypted traffic?

HTH

Rick

HTH

Rick

Hi, sorry for the long time answer

>So is your loopback interface the exit interface for encrypted traffic?

yes

See example, it works on old IOS version 12.4

crypto isakmp key TEST-IPSEC address XX.XX.XX.XX

crypto isakmp policy 20
encr aes 256
authentication pre-share
group 5
lifetime 28800
crypto ipsec transform-set AES256-SHA esp-aes 256 esp-sha-hmac
crypto map PI-IPSEC 1 ipsec-isakmp
description **TEST-IPSEC**
set peer XX.XX.XX.XX
set transform-set AES256-SHA
match address TEST-IPSEC
set security-association lifetime seconds 28800
ip access-l ex TEST-IPSEC
permit ip host <NAT-IP> host 10.4.0.7 (после NAT)
interface Loopback3
description **for IPSEC-PI**
ip address YY.YY.YY.YY 255.255.255.255
ip nat outside
ip policy route-map REROUTE
crypto map PI-IPSEC
------NAT-------
ip access-list extended XXXX
permit ip host 192.168.10.13 host 10.4.0.7
route-map XXXX permit 10
match ip address XXXX
ip nat inside source static 192.168.10.13 <NAT-IP> route-map XXXX extendable
------Reroute------
ip access-list extended REROUTE
permit ip host 192.168.10.13 host 10.4.0.7 (до NAT)
route-map REROUTE permit 6
description **for IPSEC-PI**
match ip address REROUTE
set default interface Loopback3
ip local policy route-map REROUTE

It is necessary that from my side for the new crypto map was a new IP, IP source, not the destination

Thanks for sending the example. Am I correct in understanding that this does work?

I do not understand what you mean when you say "It is necessary that from my side for the new crypto map was a new IP, IP source, not the destination" Can you clarify for me?

HTH

Rick

HTH

Rick