cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
219
Views
0
Helpful
2
Replies

Hub-Spoke problem

admin
Level 1
Level 1

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.

2 Replies 2

gfullage
Cisco Employee
Cisco Employee

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.

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.