IPSec Error

Hi All,

First off, I'd like to say "What a great group!". I've been lurking for years, and an off/on contributor, and I don't think that I've found any resource as valuable as this group. So thanks and keep up the great work folks!!!

Now then, I've been receiving the following error (%CRYPTO-4-RECVD_PKT_INV_IDENTITY) on my core WAN routers, and I have not found a reason for it. I went to Cisco's dubious value error message decoder, and all that it could say was this:

%CRYPTO-4-RECVD_PKT_INV_IDENTITY: [chars] (ip) dest_addr= [IP_address], src_addr= [IP_address], prot= [dec] (ident) local=[IP_address], remote=[IP_address] local proxy=[IP_address]/[IP_address]/[dec]/[dec], remote_proxy=[IP_address]/[IP_address]/[dec]/[dec]

A decapsulated IPSec packet does not match its negotiated identity. The peer is sending other traffic through this SA. This condition may be due to an SA selection error by the peer. This condition might be considered a hostile event.

I'm pretty sure at this point that its not a hostile event, but of course anything is possible. We encrypt everything that goes over any shared media (to include DS3 and T1s) due to HIPPA regulations, so we have a bunch of SAs terminated on these boxes. Here is the output of the show version command. I would also paste the config here, or at least part of it, but that isn't allowed because of higher ups that don't understand how IT works, and therefore have made sharing ANY parts of a config verboten.

Cisco Internetwork Operating System Software IOS (tm) 7200 Software (C7200-DK2O3S-M), Version 12.1(19)E6, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) TAC Support:

formatting link
(c) 1986-2004 by cisco Systems, Inc. Compiled Thu 15-Jan-04 00:26 by pwade Image text-base: 0x60008F88, data-base: 0x61650000

ROM: System Bootstrap, Version 12.2(4r)B2, RELEASE SOFTWARE (fc2) BOOTLDR: 7200 Software (C7200-KBOOT-M), Version 12.1(8a)E, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)

WAN-7206-1 uptime is 1 year, 8 weeks, 2 days, 22 hours, 43 minutes System returned to ROM by reload at 07:59:32 UTC Wed Jan 21 2004 System restarted at 23:08:17 daylight Wed Jan 21 2004 System image file is "disk0:c7200-dk2o3s-mz.121-19.E6.bin"

cisco 7206VXR (NPE400) processor (revision A) with 114688K/16384K bytes of memory. Processor board ID 28711167 R7000 CPU at 350Mhz, Implementation 39, Rev 3.3, 256KB L2, 4096KB L3 Cache

6 slot VXR midplane, Version 2.7

Last reset from power-on Bridging software. X.25 software, Version 3.0.0. Primary Rate ISDN software, Version 1.1.

PCI bus mb0_mb1 has 400 bandwidth points PCI bus mb2 has 480 bandwidth points

2 FastEthernet/IEEE 802.3 interface(s) 2 Serial network interface(s) 8 Channelized T1/PRI port(s) 2 Channelized T3 port(s) 1 Integrated service adapter(s) 125K bytes of non-volatile configuration memory.

47040K bytes of ATA PCMCIA card at slot 0 (Sector size 512 bytes).

8192K bytes of Flash internal SIMM (Sector size 256K). Configuration register is 0x2102

Thanks in advance for any light that y'all can shed on this!!

Regards,

-Richard

Reply to
Richard Graves
Loading thread data ...

In article , Richard Graves wrote: :Now then, I've been receiving the following error :(%CRYPTO-4-RECVD_PKT_INV_IDENTITY) on my core WAN routers, and I have not :found a reason for it.

:A decapsulated IPSec packet does not match its negotiated identity. The peer :is sending other traffic through this SA. This condition may be due to an SA :selection error by the peer. This condition might be considered a hostile :event.

I haven't configured IPSec under IOS, but the situation you describe sounds similar to a couple of situations I debugged recently on the PIX. One of these two might inspire a solution to your problem:

formatting link
?selm=cvdnbr%24ktv%241%40canopus.cc.umanitoba.ca

Reply to
Walter Roberson

Hello,

During IKE negotiations, peers exchange Identity (ID) payloads which are normally derived from IPSec ACLs. See following example from Cisco.com:

formatting link
ID payload is derived from access-list 192 in this case. The mirrored access-list should exist on remote peer for the IPSec SA to come up. Now when packet gets decrypted its IP source and destination addresses are compared against configured IPSec ACLs. If they don't match then error %CRYPTO-4-RECVD_PKT_INV_IDENTITY is generated and packet is dropped. HTH, Cheers Alex

Reply to
JNCIP#0136

formatting link
The ID payload is derived from access-list 192 in this case. The mirrored

Hi All,

Thanks for the replies. I should probably have mentioned in my original post that the SAs are establishing just fine, and data is flowing and being encrypted. Which is why these errors are so puzzling to me. One thing that the above post brings to light however is the fact that my interesting traffic ACLs are not exact mirror images of each other. I get mixed answers from Cisco on how acceptable this is.

Thanks,

-Richard

Reply to
Richard Graves

In article , Richard Graves wrote: :One thing that :the above post brings to light however is the fact that my interesting :traffic ACLs are not exact mirror images of each other. I get mixed answers :from Cisco on how acceptable this is.

Acceptability depends on context.

SPI's get allocated per proxy negotiated.

I do not know at the moment how the negotiations are -supposed- to happen, but the -effect-, in practice, is like this:

- the initiator runs the source/destination pair through it's crypto map ACLs until it finds a match, and it creates an outbound SPI around that line of the ACL, extracted from all context, and sends the SPI to the remote end.

- My recollection is that the actual endpoints of the proxy and associated masks are offered to the remote end, but for the PIX at least, events are most easily explained by supposing that either it does not offer the proxy or else that the remote PIX pretty much ignores the proxy entry. Instead, the remote PIX looks up the source and destination IP in its own crypto map ACL, and creates an outbound SPI around that, which gets sent back to the originator.

- One now has two outbound SPIs created and cross-transmitted to become inbound SPIs on the other side.

- Because (in effect) the two ACL entries were looked up seperately on the two ends, the two SPIs may have mismatched proxies.

- When there is a packet to send, the source and destination is looked up in the active entries in order to determine the proper SPI to transmit with. Only one direction needs to be search for this, since the SPIs are unidirectional: for a given source/destination pair, there is one SPI in one direction and a different SPI in the other direction.

- When the packet gets to the other end, source and destination is going to be looked up in the receipt SPI table, and the SPI entry from there used to decode the traffic.

- When there is a proxy mismatch, then you are okay as long as the mismatch is such that all of the -actual- data transmitted falls within the same SPI pair.

- If a transmitter sends a packet that matches the proxy for a particular SPI, but does not match any SPIs (active or potential) at the other end, then the other end will reject the packet as being unexpectedly encapsulated.

- If a transmitter sends a packet that matches the proxy for a particular SPI, but matches a -different- SPI pair at the other end, then the packet will not decode properly and you will get strange messages.

- If a transmitter sends a packet that does not match any proxy on its end, but does match a proxy on the other end, then the packet will be sent plain, and the other end will reject the packet with the famous "rec'd packet is not an ipsec packet" message.

- If you put this together, you can see that packets might flow just fine between some systems, but not get through to others. For example, if the two ends have near twin ACLs but the netmasks differ, then transmissions will work for hosts where the masks overlap, but will fail if one of the endpoints is outside the mask of one of the sides.

- One subtle issue that bears remarking on, is that one might potentially have crypto map entries that permit traffic with various local subsets, with all the entries together covering the whole set. For example, suppose one happens to have two entries, one for 10.2.3.0 255.255.255.128 and the other with the same information but covering 10.2.3.128 255.255.255.128. On the other end, knowing that traffic is permitted for the entire set, one might write the acl as 10.2.3.0 255.255.255.0 . One end is expecting one SPI for the entire range, but the other end expects two SPIs -- IPSec does NOT know enough to merge adjacent ranges. Traffic may work if it happens to be entirely to one half or the other, but there will be Problems if the side that has the whole range tries to transmit to both halfs of what the other side knows as multiple pieces.

- What makes the above even more subtle is that sometimes *both* directions will work perfectly, with it being dependant upon which end initiated the traffic. Recall that above I wrote about the -effect-, rather than about what the standards say. The real effect is more subtle: the entire proxy will get transferred and activated in some [ill-defined] circumstances... but if it happens that it is the other side which initiates the renegotation of the SPIs after a time, then the data transfer can just suddenly stop working.

- There are more complications than hinted at above, involving cases where the remote endpoint of a crypto tunnel happens itself to be reachable via a crypto tunnel. You get some bad mojo happening in such cases. :(

Reply to
Walter Roberson

It's not OK. We escalated these types of IPSec issues as high as it goes within Cisco. We did it twice in 7 months due to IPSec bugginess and general lack of robustness. That's putting it in a politically correct way I suppose. There were some design issues as well so I can't fault Cisco 100%.

You may find that bugs pop up when you configure IPSec in a different method than what Cisco wants. For example, if you ACL has an "IP match" then a "TCP match" in consecutive lines, you can have issues. Some HW/SW combo will use the TCP match criteria because it's "more specific" Others will use the first line as the match since it's valid. Now you have an SPI mismatch and things go awry.

Also, I see that you're on 12.1(19)E6 version. I'm pretty sure we migrated from .19 to (20)E5 version. .20 had some major IPSec issues addressed and E5 added SNMP support for IPSec. I'll double check the IOS version though and repost tomorrow.

Reply to
Hansang Bae

Hansang,

Thanks for your input, I've been debating an enterprise-wide upgrade to

12.3(8)T3 to gain access to the extended IPSec features in that release (more granular show cmds, etc), as well as the IDS features, limited as they are. However, I've notice a major IPSec incompatibility between 12.1(19)E6 and 12.3(8)T3. When you try to establish a tunnel between the two IOS versions, data throughput is reduce by something like 80%, and even establishing the tunnel is a 50/50 shot.

It may be time to delve a little deeper into the full-scale upgrade in the lab to see what happens. Thanks again!

-Richard

Reply to
Richard Graves

Walter,

Thanks for that great explaination. I tried to e-mail you directly today, but I'm not sure you got it. I wanted to be sure that I thanked you for that last post.

Thanks again!

-Richard

Reply to
Richard Graves

Richard, don't rush into that 12.3(8)T3 without some thorough testing. We found an issue a few weeks ago (I think that was the exact IOS) that sometimes it wouldn't generate new SA after the old SA expires, and would drop VPN tunnel because of it.

I'll have to look it up if that was exact IOS version, but you can look it up on Bug Tool on CCO.

Reply to
Ivan Ostreš

Hansang Bae wrote: [snip]

OK, we're getting ready to test E5. But we are still on E3 at the moment. E4 had some issues with using 'deny' in crypto acls.

Reply to
Hansang Bae

Seems you guys have a pretty decent testing department when you're able to find all this errors before putting stuff in production.

Reply to
Ivan Ostreš

Cisco does quite a bit of work for us! :) But we also found major issues in pre-pilot rollouts.

Reply to
Hansang Bae

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.