09-25-2003 10:06 AM - edited 03-09-2019 04:55 AM
I am having trouble with my hub-spoke setup.
Cisco2611_ILM hub site
Cisco1750_MYR spoke1
Cisco2610_CLT spoke2
The first spoke to complete its IKE phases will work correctly while the second will not. Both spokes successfully complete IKE phases with the following results:
---
Cisco2611_ILM#sho cry eng conn act
ID Interface IP-Address State Encrypt Decrypt
10 <none> <none> ---------set ------0 0 -------ISAKMP
11 <none> <none> ---------set ------0 0 -------ISAKMP
2000 E0/1 xx.xxx.xxx.xx --set ------0 6241 ----MYRinbound
2001 E0/1 xx.xxx.xxx.xx --set ---5317 0 -------MYRoutbound
2002 E0/1 xx.xxx.xxx.xx --set ------0 0 -------CLTinbound
2003 E0/1 xx.xxx.xxx.xx --set ----940 0 -------CLToutbound
---
Cisco2610_CLT#sho cry eng conn act
ID Interface IP-Address State Encrypt Decrypt
1 <none> <none> ----------set ------0 0 -------ISAKMP
2000 FE1/0 xx.xx.xxx.xx --set ------0 1031 ----ILMinbound
2001 FE1/0 xx.xx.xxx.xx --set ------1675 0 ----ILMoutbound
Notice that the hub router (ILM) does not show decrypts for the CLT inbound traffic. If I force the CLT tunnel up first and then the MYR tunnel, the MYR tunnel will have this same problem.
This is currently an IPSEC only vpn but I had the same problem with a GRE/IPSEC vpn between the same sites. I have eliminated my inbound access-lists on the public interfaces as a problem by turning them off and still experiencing the same results. Debug out put appears normal.
While the second tunnel is up, I receive the following error at the hub router once per minute:
1d00h: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed connection id=2000
Any help would be greatly appreciated.
09-28-2003 08:10 PM
Can you post your hub and spoke config (just one spoke should be fine)? Please change public IP addresses to something other than the actual address, and xxxx out your password entries.
09-29-2003 03:56 AM
I solved this problem over the weekend by removing all the crypto commands on all the routers and reentering them which I know sounds like a syntax problem but I am sure the commands are the same now as before.
I suspect there was some problem with the crypto engine on the hub router that caused the second tunnel?s inbound ipsec packets to be seen as packets inbound on the first tunnel. Since the spi didn?t match in that case they were dropped.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide