%CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.

Hi Everyone.
I was making some changes in routers and after I rolled back configuration a gre tunnel won't work. It's GRE Tunnel between a Cisco 7600 and Cisco 2851.
It seems like 7600 sent packets unencrypted.
On C2851 is received this message:
%CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.
(ip) vrf/dest_addr= /10.0.0.10, src_addr= 10.0.0.18, prot= 47
Could you check configuration attached and give any advise.
Thank you.

I went through the configuration and think all required components are in there.
I would say that we should check routing.
Error message means that packet recieved as per local policy should have been a IPSEC encrypted packet however it was a plain text packet.
going further:
* Please check if tunnel is up and share show crypto ipsec sa from either end.
* please check if the packets leaving other end are taking right exit interface and if yes are they encrypted or not. you can check this with the help of ACL (disabling CEF if this is not into production and there is no MPLS link involved).

Similar Messages

%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

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.

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

Master data HR to E-REC standalone system not being created using PFAL

I am trying to transfer data from HR to standalone E-REC system using PFAL transcation.
IDOC transferred with Status 53.
BADIS of E-rec are Implemented.
In e-rec relationship O to S, S to CP, CP to US, CP to BP and CP to P are getting created Properly in table HRP1001.
We are unable to see the data for Infotypes 0000,0001,0002,0006,0105 for the same CP in PP01.
We tried the same scenario with SRM system and there we were able to see the data of above infotypes for a CP.
Table T77S0 are maintained according to the SAP notes.
Please through some light on how we can transfer the data of HR master to E-rec and where exactly we have to check for this master data in E-REC
Thanks in Advance.

Dear Rohit,
Firstly,
No, you cannot have infotypes like how you have mentioned for SRM. This is not how it is in eRecruiting. As Raj suggested, we look at other infotypes of this.
5102 : gives you details about the candidates.Object NA.
5105: Qualification details etc.
For an object P in the system, there is CP. On activating the relevant BADIs, a BP & NA are created for the CP when transferring data from core HR. Now, this does not necessarily mean that all the HR infotypes are transferred to relvant infotypes in eRecruiting. The data is handled differently.
If you are sure that NA exists, then internal candidates are created successfully. Next thing would be to map this NA object with the relevant PA details like name, address,email address etc. For this we make use of the BP object associated with the CP & not the CP or the NA.
So, if you would want to check if the transfer is successful then you go to tcode BP & check if the name & address details etc are the same as the corresponding P for which the NA is created.
To see more of the core HR info, you can check the business partner BUT000 against the relevant BP.
I hope this clears some of your confusion.
Secondly,
Regarding the BADI, I am aware that this BADi is mainly required in an integration implementation scenario. But i think the sample implementation of this BADI CONV_HR_DATA_TO_EREC is required to create internal candidates from idocs.I think this is required for the P to CPBPNA transformation.But if you say the NA is created without this then maybe i am wrong. Please take a second look at this.
Regards,
Sowmya

Crypto map mymap command I am not familiar with

I have the following commands in a new pix I am taking over and I am not sure what they do?
crypto map mymap client configuration address initiate
crypto map mymap client configuration address respond
any help would be appreciated

Hi .. they are used for remote VPNs:
1.- crypto map mymap client configuration address initiate
explanation: Use the crypto map mymap for remote vpn clients and the PIX Firewall will attempt to set IP addresses for each client.
2.- crypto map mymap client configuration address respond
explanation: Use the crypto map mymap for remote vpn clients and the PIX Firewall will accept requests for IP addresses from any
requesting client.
I hope it helps .. please rate if it does !!

Replaced ram with 1333MHz instead of rec'd 1066MHz, not working

Hi,
I have upgraded my ram to 8gb of 1333Mhz from 2gb 1066mhz. The bus speed is 1066, but it should work from what i understand. The only reason I went with the 1333mhz is because it was on sale for cheaper than 1066. It is installed, but the mac will not even start up. Instead it beeps and the sleep light flashes. Is they're any explanation? Or should I just return it and buy the 1066?
Thank you.

Bmack19 wrote:
should I just return it and buy the 1066?
yes.

E-REc : Recruiter Dropdown not populated during Requisition

Please do not ask for or offer points. It is against the rules of the forum.
Hi All,
While creating Manpower Requisition through MSS on Portal, system does not populate Recruiter dropdown in the Adobe form.
I have checked in the HR system that feature PINCH is properly created and called and accordingly table T526 is maintained with proper Recruiter user ID. The same User Id also has recrutier role assigned in Erec System.
Do I need to check some other point in HR or Erec system?
Helpful answers with be rewarded with points for sure
Thanks.
-Tejas
Edited by: Matt on Sep 23, 2010 10:31 AM

Hello,
In EhP4 what package do you have? Check if note 1318164 is already applied because in earlier versions it was not possible to to see the activities if you were not assigned directly to the support team in HRP5131. The system was not considering those assigned through a support group until the note was released. So you can compare your versions and also check if you are able to see if you assign someone directly as a support team member and not through a support group.
Regards,

Pre-rec'd CD not recognized

I just got my Nano. While I was charging it, I had no problem having a CD recognized. Now, I'm on and have my iTunes account set-up, and I am all kinds of CD problems.
An audio CD is not recognized when I want to import. I think I have all Windows updates; I followed directions from Help t re-open iTunes, etc.
Another CD problem with burning CDs. the app tells me that the CD-R is not blank, even though is just out of the plastic wrap.

Yes - sorry I forgot to answer that.
When I manually try the GET CD TRACK NAMES the CDDB window briefly opens and seems to run properly. But nothing changes on the track list or cd name.
Also I am not getting any CD's visible at all anymore in itunes. I have to use RealPlayer to save a CD to my library then drag the folder to itunes to have it recognize it.
Weird!!

Rec JDBC - data not inserted to DB

Hi,
In Proxy to JDBC scenario, data is not inserted to DB (Sqlserver).
From proxy, xi could able to get data; in moni it is showing success flag. But data is not inserted to DB. Connectivity is there from XI to DB.
We are using SP to insert the data.
When checking in Message monitoring, it is showing as success but when checking in CC monitoring, the channel status is showing as Functioning. No other data is provided.
Please share your ideas where it went wrong.
Regards,
Anil.

Hi
Ur target structure should be like this for SP - Is it the same?
/people/siva.maranani/blog/2005/05/21/jdbc-stored-procedures
http://help.sap.com/saphelp_erp2004/helpdata/en/d2/bab440c97f3716e10000000a155106/frameset.htm
Use asinput and type
Instead of SP u can directly use the INSERT action and table name which will also serve the same purpose.
chirag

E-REC: System is not following new Lead recruiter

Hi All,
I have an issue with Requisition mgmt.
We are using EHP4, issue can be reproduced like below...
1. Create a requisition. with your login.
2. Release it.
3. Again EDIT the requisition and change the Lead recruiter to new Lead recruiter.
4. Requisition will be in 'Draft' status. So just release it.
5. Check Support team to the released requisition by using 'CL_HRRCF_M_SUPPORT_GROUP_UI->Get_support_ team' or go to
SE16 and check in the table HRP5131(person responsible). If you check the role '0015', it will be the old leadrecruiter only.
6. New Lead recruiter is not updated in the backend due to some reasons.
Any one come accross this situation? Please help me to solve the issue.
Regards,
Anil

Hello Anil,
Please check the following notes help in this case :
1527715 Adjust support team for lead recruiter and hiring
1423073
Best Regards,
Deepak.

TS3694 Rec'd a note to update iTunes to version 11.1.4 on my PC. All was routine until an error message appeared: "MSVCR80.dll is missing". I''m at a loss as to how to fix this. Help

Can't download and install iTunes update to version 11.1.4 without receiving an error message: "MSVCR80.dll is missing". What do I do?

Click here and follow the instructions. You may need to completely remove and reinstall iTunes and all related components, or run the process multiple times; this won't normally affect its library, but that should be backed up anyway.
(99804)

DMVPN Issues - IPsec packets

Hi All,
I am currently trying to configure DMVPN for the first time. I have been following the cisco config guide and googling a few other bits however I seem to have hit a brick wall.
The setup is in a lab environment so i can post up as much info as required but here are the important bits:
I have 3 Cisco 2821 routers running IOS 12.4(15) with a Layer 3 switch in the middle connecting the "wan" ports together. the routing is working fine, I can ping each router from each other router.
A few snippets from the hub router config:
crypto ipsec transform-set DMVPN_SET esp-3des esp-md5-hmac!crypto ipsec profile DMVPN_PRJ set transform-set DMVPN_SET!interface Tunnel0 bandwidth 10000 ip address 172.17.100.1 255.255.255.0 no ip redirects ip mtu 1500 ip nhrp authentication secretid ip nhrp map multicast dynamic ip nhrp network-id 101 ip nhrp holdtime 450 ip tcp adjust-mss 1460 tunnel source GigabitEthernet0/0 tunnel mode gre multipoint tunnel key 10101 tunnel protection ipsec profile DMVPN_PRJ!interface GigabitEthernet0/0 description HQ WAN ip address 1.1.1.1 255.255.255.248 ip nat outside ip virtual-reassembly duplex auto speed auto!
and heres the config on the first spoke router:
crypto ipsec transform-set DMVPN_SET esp-3des esp-md5-hmac!crypto ipsec profile DMVPN_PRJ set transform-set DMVPN_SET!interface Tunnel0 bandwidth 3000 ip address 172.17.100.10 255.255.255.0 no ip redirects ip mtu 1500 ip nhrp authentication secretid ip nhrp map 172.17.100.1 1.1.1.1 ip nhrp map multicast 1.1.1.1 ip nhrp network-id 101 ip nhrp holdtime 450 ip nhrp nhs 172.17.100.1 ip tcp adjust-mss 1460 tunnel source GigabitEthernet0/0 tunnel mode gre multipoint tunnel key 10101 tunnel protection ipsec profile DMVPN_PRJ!interface GigabitEthernet0/0 description Site 1 WAN ip address 11.11.11.1 255.255.255.248 ip nat outside ip virtual-reassembly duplex auto speed auto!
if I shut/no shut the tunnel0 interface on spoke 1, I get the following error on the hub router:
Mar 30 13:41:17.075: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.        (ip) vrf/dest_addr= /1.1.1.1, src_addr= 11.11.11.1, prot= 47
so I feel im missing some config on the spoke side to encrypt the traffic but im not sure what.
the following are outputs from the spoke router:
RTR_SITE1#sh dmvpn detailLegend: Attrb --> S - Static, D - Dynamic, I - Incompletea        N - NATed, L - Local, X - No Socket        # Ent --> Number of NHRP entries with same NBMA peer -------------- Interface Tunnel0 info: --------------Intf. is up, Line Protocol is up, Addr. is 172.17.100.10   Source addr: 11.11.11.1, Dest addr: MGRE Protocol/Transport: "multi-GRE/IP", Protect "DMVPN_PRJ",Tunnel VRF "", ip vrf forwarding ""NHRP Details: NHS:       172.17.100.1 EType:Spoke, NBMA Peers:1# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb    Target Network----- --------------- --------------- ----- -------- ----- -----------------    1         1.1.1.1    172.17.100.1   IKE    never S       172.17.100.1/32 Interface: Tunnel0Session: [0x48E31B98] Crypto Session Status: DOWN fvrf: (none),   IPSEC FLOW: permit 47 host 11.11.11.1 host 1.1.1.1        Active SAs: 0, origin: crypto map   Outbound SPI : 0x       0, transform :    Socket State: ClosedPending DMVPN Sessions:
RTR_SITE1#sh ip nhrp detail172.17.100.1/32 via 172.17.100.1, Tunnel0 created 00:33:44, never expire Type: static, Flags: used NBMA address: 1.1.1.1
RTR_SITE1#sh crypto ipsec sainterface: Tunnel0    Crypto map tag: Tunnel0-head-0, local addr 11.11.11.1   protected vrf: (none)   local ident (addr/mask/prot/port): (11.11.11.1/255.255.255.255/47/0)   remote ident (addr/mask/prot/port): (1.1.1.1/255.255.255.255/47/0)   current_peer 1.1.1.1 port 500     PERMIT, flags={origin_is_acl,}    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0    #pkts compressed: 0, #pkts decompressed: 0    #pkts not compressed: 0, #pkts compr. failed: 0    #pkts not decompressed: 0, #pkts decompress failed: 0    #send errors 46, #recv errors 0     local crypto endpt.: 11.11.11.1, remote crypto endpt.: 1.1.1.1     path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0     current outbound spi: 0x0(0)     inbound esp sas:     inbound ah sas:     inbound pcp sas:     outbound esp sas:     outbound ah sas:     outbound pcp sas:
All of these commands show up as blank when i run them on the hub router.
Any help appreciated.
Thanks

Thanks for the help
I was following this guide: http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_DMVPN.html#wp1118625
I am using NAT, g0/1 on the routers in the LAN interface with a difference 10.x.x.x/24 on each router.
isakmp policy solved my issue, fixed the MTU as well.
What do i need to add to allow the 10.x.x.x networks to use the tunnels to communicate? I can now ping each end of the tunnel from both routers but not the LAN interfaces.
Thanks

GDOI IPsec SA Failures

Need help understanding IPSEC Packet errors running in a GDOI environment.
Everything runs fine for hours (random # of hours) and then we receive the following errors;
(ip) vrf/dest_addr= /1.1.1.1, src_addr= 2.2.2.2, prot= 50 Dec 21 05:34:09 EST: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC pa
cket.
Each time this happened, it took a CLEAR CRYPTO GDOI to get traffic going again.
It doesn't appear to be anything related to Rekeying and it's confusing because the Prot reported in the message is 50 (ESP) - so it appears that traffic is still being sent encrypted.
We are using VPN Hardware accelaration ( AIM-VPN/SSL-3) and I don't see any errors there.
I'm not certain where to look next - any help out there?

What we found is that the return reply, from what appears to be because of Netflow payload being fragmented, is the cause of the IPSEC error.
If we open the "do not encrypt" acl to include not just the initial UDP + Port for the NetFlow send, but also include all IP, we are able to get Netflow traffic across and eliminate the IPSEC error.
Although this is working, it is not ideal.
Are there any options to avoid Netflow payload fragmentation?
Initially, MTU size had to be set to 1400 for GETVPN traffic to flow successfully in both directions. This looks to be impacting Netflow.
Thanks.

GETVPN Group Member and Netflow

Hi,
We've recently migrated some remote sites on to new WAN links, and configured GETVPN on these remote Routers. Connectivity is working as expected, I'm just having issues in getting netflow working correctly. It appears that the spoke router is attempting to send the Netflow data, but when it's hitting the Hub Router, I'm seeing %IPSEC-3-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet within the logs.
Having seem some similar issues flagged, I've modified the Netflow configuration to replicate the below (which now includes the output features command within the flow exporter) but the IPSEC-3-RECVD_PKT_NOT_IPSEC log messages still persist. The ipsec config is currently set so that the Netflow traffic should be encrypted.
flow exporter Test
description Netflow export to Netflow-Server
destination *.*.*.*
source Loopback0
output-features
transport udp 2055
flow monitor Test
record netflow-original
exporter Test
Am I missing something within the configuration - Router in question is a Cisco 3845, running 15.1(4)M5
TIA

Hi Daniel,
Well know feature - netflow was not supported with ipsec (netflow packets not encrypted even when hitting ipsec policy).
But for flexible netflow it works when you enable "output feature":
https://supportforums.cisco.com/docs/DOC-13452
Michal

LogicX Rec Problem. I can't hear while recording no matter I turn on Auto Input Monitoring at menu or channel. On certain songs I could thru AUX to REC, my L7/8/9 procedure. Now, inconsistent, not work. Any help?

Logic X Recording Problem
I can't hear (ex.) voice back while recording no matter I turn on Auto Input Monitoring at Record Menu or Channel Strip.
On certain old projects I could when thru AUX to REC, which was my L7/8/9 procedure.
Recording takes place on a consolidated session, all audio tracks with no latency, which actually happens only it can't be heard.
Monitoring is very inconsistent and in fact doesn't work at all. Any help?
Mac Pro 2010 2x2.66 12 Core 32GB OSX 10.9.5 SSD 480
Recording on HD 1TB, Fireface 800

Correction: actually "thru AUX to REC channel" is not effective.
It's just that I can input monitor thru an extra AUX channel independently of the REC channel.
Sending the source to be recordered to aux and audio rec at same time.
Mac Pro 2010 2x2.66 12 Core 32GB OSX 10.9.5 SSD 480
Recording on HD 1TB, Fireface 800

Getting "IPSEC(epa_des_crypt): decrypted packet failed SA identity check" messages on packets from only one of two far-end sources sharing the same tunnel, the other source works fine. What exactly does this error mean?

One computer at COMPANY-A is attempting to communicate with two
computers located at COMPANY-B, via an IPsec tunnel between the
two companies.
All communications are via TCP protocol.
All devices present public IP addresses to one another, although they
may have RFC 1918 addresses on other interfaces, and NAT may be in use
on the COMPANY-B side. (NAT is not being used on the COMPANY-A side.)
The players:(Note: first three octets have been changed for security reasons)
COMPANY-A computer      1.2.3.161
COMPANY-A router        1.2.3.8 (also IPsec peer)
COMPANY-A has 1.2.3.0/24 with no subnetting.
COMPANY-B router        4.5.6.228 (also IPsec peer)
COMPANY-B computer #1   4.5.7.94 (this one has no issues)
COMPANY-B computer #2   4.5.7.29 (this one fails)
COMPANY-B has 4.5.6.0/23 subnetted in various ways.
COMPANY-B also has 9.10.11.0/24, but it is not involved in the issue.
What works:
The COMPANY-A computer 1.2.3.161 can communicate via the single IPsec
tunnel to COMPANY-B computer #1 4.5.7.94 without problems.
The "show crypto session detail" command shows Inbound/Outbound packets
flowing in the dec'ed and enc'ed positions.
What doesn't:
When the COMPANY-A computer 1.2.3.161 attempts to communicate
via the single IPsec tunnel with the COMPANY-B computer #2 4.5.7.29,
the COMPANY-A router eventually reports five of these messages:
Oct 9 15:24:54.327: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Oct 9 15:24:57.327: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Oct 9 15:25:03.327: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Oct 9 15:25:15.328: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Oct 9 15:25:39.329: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Oct 9 15:26:27.328: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
and the "show crypto session detail" shows inbound packets being dropped.
The COMPANY-A computer that opens the TCP connection never gets past the
SYN_SENT phase of the TCP connection whan trying to communicate with the
COMPANY-B computer #2, and the repeated error messages are the retries of
the SYN packet.
On the COMPANY-A side, this IPsec configuration has been set up on a 3745,
a 3725, and some 76xx routers were tried, all with similar behavior,
with packets from one far-end computer passing fine, and packets from
another far-end computer in the same netblock passing through the same
IPsec tunnel failing with the "failed SA identity" error.
The COMPANY-A computer directs all packets headed to COMPANY-B via the
COMPANY-A router at 1.2.3.8 with this set of route settings:
netstat -r -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window irtt Iface
4.5.7.0         1.2.3.8         255.255.255.0   UG        0 0          0 eth3
1.2.3.8.0       0.0.0.0         255.255.255.0   U         0 0          0 eth3
10.1.0.0        0.0.0.0         255.255.240.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth3
10.0.0.0        10.1.1.1        255.0.0.0       UG        0 0          0 eth0
0.0.0.0         1.2.3.1         0.0.0.0         UG        0 0          0 eth3
The first route line shown is selected for access to both COMPANY-B computers.
The COMPANY-A router (IPsec tunnel endpoint, 1.2.3.8) has this
configuration:
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
lifetime 28800
crypto isakmp key XXXXXXXXXXXXXXXXXXXXXXX address 4.5.6.228
crypto ipsec security-association lifetime seconds 86400
crypto ipsec transform-set COMPANY-B01 esp-3des esp-sha-hmac
crypto map COMPANY-BMAP1 10 ipsec-isakmp
description COMPANY-B VPN
set peer 4.5.6.228
set transform-set COMPANY-B01
set pfs group2
match address 190
interface FastEthernet0/0
ip address 1.2.3.8 255.255.255.0
no ip redirects
ip virtual-reassembly
duplex auto
speed auto
no cdp enable
crypto map COMPANY-BMAP1
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 1.2.3.1
ip route 10.0.0.0 255.0.0.0 10.1.1.1
ip route 1.2.3.8.0 255.255.255.0 FastEthernet0/0
access-list 190 permit ip host 1.2.3.161 4.5.7.0 0.0.0.255
access-list 190 permit ip host 1.2.3.161 9.10.11.0 0.0.0.255
bridge 1 protocol ieee
One of the routers tried had this IOS/hardware configuration:
Cisco IOS Software, 3700 Software (C3725-ADVIPSERVICESK9-M), Version 12.4(25c),
RELEASE SOFTWARE (fc2)
isco 3725 (R7000) processor (revision 0.1) with 115712K/15360K bytes of memory.
Processor board ID XXXXXXXXXXXXXXX
R7000 CPU at 240MHz, Implementation 39, Rev 3.3, 256KB L2 Cache
2 FastEthernet interfaces
4 ATM interfaces
DRAM configuration is 64 bits wide with parity disabled.
55K bytes of NVRAM.
31296K bytes of ATA System CompactFlash (Read/Write)
250368K bytes of ATA Slot0 CompactFlash (Read/Write)
Configuration register is 0x2102
#show crypto sess
Crypto session current status
Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 4.5.6.228 port 500
IKE SA: local 1.2.3.8/500 remote 4.5.6.228/500 Active
IPSEC FLOW: permit ip host 1.2.3.161 4.5.7.0/255.255.255.0
        Active SAs: 2, origin: crypto map
IPSEC FLOW: permit ip host 1.2.3.161 9.10.11.0/255.255.255.0
        Active SAs: 0, origin: crypto map
#show crypto sess det
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, X - IKE Extended Authentication
Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 4.5.6.228 port 500 fvrf: (none) ivrf: (none)
      Phase1_id: 4.5.6.228
      Desc: (none)
IKE SA: local 1.2.3.8/500 remote 4.5.6.228/500 Active
          Capabilities:(none) connid:1 lifetime:06:26:27
IPSEC FLOW: permit ip host 1.2.3.161 4.5.7.0/255.255.255.0
        Active SAs: 2, origin: crypto map
        Inbound: #pkts dec'ed 651 drop 16 life (KB/Sec) 4496182/23178
        Outbound: #pkts enc'ed 574 drop 2 life (KB/Sec) 4496279/23178
IPSEC FLOW: permit ip host 1.2.3.161 9.10.11.0/255.255.255.0
        Active SAs: 0, origin: crypto map
        Inbound: #pkts dec'ed 0 drop 0 life (KB/Sec) 0/0
        Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 0/0
The COMPANY-B device on their end of the IPsec VPN is a Juniper SSG1000
Version 6.1 (ScreenOS)
We only have a limited view into the Juniper device configuration.
What we were allowed to see was:
COMPANY-B-ROUTER(M)-> sh config | incl COMPANY-A
set address "Untrust" "oss-COMPANY-A-1.2.3.161" 1.2.3.161 255.255.255.255
set ike gateway "COMPANY-A-1-GW" address 1.2.3.8 Main outgoing-interface "ethernet2/1" preshare xxxxxxxxxxxxxxxxxxxxxx proposal "pre-g2-3des-sha"
set vpn "COMPANY-A-1-IKE" gateway "COMPANY-A-1-GW" no-replay tunnel idletime 0 proposal "g2-esp-3des-sha-28800"
set policy id 2539 from "Untrust" to "Trust" "oss-COMPANY-A-1.2.3.161" "9.10.11.0-24" "ANY" tunnel vpn "COMPANY-A-1-IKE" id 0x309a pair-policy 2500
set policy id 2500 from "Trust" to "Untrust" "9.10.11.0-24" "oss-COMPANY-A-1.2.3.161" "ANY" tunnel vpn "COMPANY-A-1-IKE" id 0x309a pair-policy 2539
set policy id 2541 from "Trust" to "Untrust" "4.5.7.0-24" "oss-COMPANY-A-1.2.3.161" "ANY" tunnel vpn "COMPANY-A-1-IKE" id 0x309b pair-policy 2540
set policy id 2540 from "Untrust" to "Trust" "oss-COMPANY-A-1.2.3.161" "4.5.7.0-24" "ANY" tunnel vpn "COMPANY-A-1-IKE" id 0x309b pair-policy 2541
COMPANY-B-ROUTER(M)->
I suspect that this curious issue is due to a configuration setting on the
Juniper device, but neither party has seen this error before. COMPANY-B
operates thousands of IPsec VPNs and they report that this is a new error
for them too. The behavior that allows traffic from one IP address to
work and traffic from another to end up getting this error is also unique.
As only the Cisco side emits any error message at all, this is the only
clue we have as to what is going on, even if this isn't actually an IOS
problem.
What we are looking for is a description of exactly what the Cisco
IOS error message:
IPSEC(epa_des_crypt): decrypted packet failed SA identity check
is complaining about, and if there are any known causes of the behavior
described that occur when running IPsec between Cisco IOS and a Juniper
SSG device. Google reports many other incidents of the same error
message (but not the "I like that IP address but hate this one" behavior),
and not just with a Juniper device on the COMPANY-B end, but for those cases,
not one was found where the solution was described.
It is hoped that with a better explanation of the error message
and any known issues with Juniper configuration settings causing
this error, we can have COMPANY-B make adjustments to their device.
Or, if there is a setting change needed on the COMPANY-A router,
that can also be implemented.
Thanks in advance for your time in reading this, and any ideas.

Hello Harish,
It is believed that:
COMPANY-B computer #1   4.5.7.94 (this one has no issues)
COMPANY-B computer #2   4.5.7.29 (this one fails)
both have at least two network interfaces, one with a public IP address
(which we are supposedly conversing with) and one with a RFC 1918 type
address.   COMPANY-B is reluctant to disclose details of their network or
servers setup, so this is not 100% certain.
Because of that uncertainty, it occurred to me that perhaps COMPANY-B
computer #2 might be incorrectly routing via the RFC 1918 interface.
In theory, such packets should have been blocked by the access-list on both
COMPANY-A router, and should not have even made it into the IPsec VPN
if the Juniper access settings work as it appears they should. So I turned up
debugging on COMPANY-A router so that I could see the encrypted and
decrypted packet hex dumps.
I then hand-disassembled the decoded ACK packet IP header received just
prior to the "decrypted packet failed SA check" error being emitted and
found the expected source and destination IP addresses (4.5.7.29 and 1.2.3.161),
in the unecapsulated packet. I also found the expected port numbers of the TCP
conversation that was trying to be established in the TCP header. So, it
looks like COMPANY-B computer #2 is emitting the packets out the right
interface.
The IP packet header of the encrypted packet showed the IP addresses of the
two routers at each terminus of the IPsec VPN, but since I don't know what triggers
the "SA check" error message or what it is complaining about, I don't know what
other clues to look for in the packet dumps.
As to your second question, "can you check whether both encapsulation and
decapsulation happening in 'show crypto ipsec sa'",   the enc'ed/dec'ed
counters were both going up by the correct quantities. When communicating
with the uncooperative COMPANY-B computer #2, you would also see the
received Drop increment for each packet decrypted. When communicating
with the working COMPANY-B computer #1, the Drop counters would not
increment, and the enc'ed/dec'ed would both increment.
#show crypto sess det
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, X - IKE Extended Authentication
Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 4.5.6.228 port 500 fvrf: (none) ivrf: (none)
      Phase1_id: 4.5.6.228
      Desc: (none)
IKE SA: local 1.2.3.8/500 remote 4.5.6.228/500 Active
          Capabilities:(none) connid:1 lifetime:07:59:54
IPSEC FLOW: permit ip host 1.2.3.161 4.5.7.0/255.255.255.0
        Active SAs: 2, origin: crypto map
        Inbound: #pkts dec'ed 376 drop 5 life (KB/Sec) 4458308/28784
        Outbound: #pkts enc'ed 401 drop 3 life (KB/Sec) 4458308/28784
Attempt a TCP communication to COMPANY-B computer #2...
show crypto sess det
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, X - IKE Extended Authentication
Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 4.5.6.228 port 500 fvrf: (none) ivrf: (none)
      Phase1_id: 4.5.6.228
      Desc: (none)
IKE SA: local 1.2.3.8/500 remote 4.5.6.228/500 Active
          Capabilities:(none) connid:1 lifetime:07:59:23
IPSEC FLOW: permit ip host 1.2.3.161 4.5.7.0/255.255.255.0
        Active SAs: 2, origin: crypto map
        Inbound: #pkts dec'ed 376 drop 6 life (KB/Sec) 4458307/28753
        Outbound: #pkts enc'ed 402 drop 3 life (KB/Sec) 4458307/28753
Note Inbound "drop" changed from 5 to 6. (I didn't let it sit for all
the retries.)
#show crypto ipsec sa
interface: FastEthernet0/0
    Crypto map tag: COMPANY-BMAP1, local addr 1.2.3.8
   protected vrf: (none)
   local ident (addr/mask/prot/port): (1.2.3.161/255.255.255.255/0/0)
   remote ident (addr/mask/prot/port): (4.5.7.0/255.255.255.0/0/0)
   current_peer 4.5.6.228 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 402, #pkts encrypt: 402, #pkts digest: 402
    #pkts decaps: 376, #pkts decrypt: 376, #pkts verify: 376
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 3, #recv errors 6
     local crypto endpt.: 1.2.3.8, remote crypto endpt.: 4.5.6.228
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0xDF2CC59C(3744253340)
inbound esp sas:
      spi: 0xD9D2EBBB(3654478779)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2004, flow_id: SW:4, crypto map: COMPANY-BMAP1
        sa timing: remaining key lifetime (k/sec): (4458307/28600)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE
     inbound ah sas:
     inbound pcp sas:
     outbound esp sas:
      spi: 0xDF2CC59C(3744253340)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2003, flow_id: SW:3, crypto map: COMPANY-BMAP1
        sa timing: remaining key lifetime (k/sec): (4458307/28600)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE
     outbound ah sas:
     outbound pcp sas:
The "send" errors appear to be related to the tunnel reverting to a
DOWN state after periods of inactivity, and you appear to get one
each time the tunnel has to be re-negotiated and returned to
an ACTIVE state. There is no relationship between Send errors
incrementing and working/non-working TCP conversations to the
two COMPANY-B servers.
Thanks for pondering this very odd behavior.

%CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.

Similar Messages

Maybe you are looking for