PIX VPN error - PIX-4-402101

May 19, 2005 2 Replies

I have a new DSL setup at a remote site using a 1751 router with IOS



12.3(14)T1 with a VPN tunnel back to a PIX 515e running Version 6.3(3). While maintaining a continuous ping to the remote router from the central office, I still see tunnel disconnects. The PIX reports the following a couple of times before dropping the tunnel: %PIX-4-402101: decaps: rec'd IPSEC packet has invalid spi for destaddr=XXX.XXX.XXX.XXX, prot=esp, spi=0xnnnn1f4(nnnn8500)

After dropping the tunnel, it immediately comes back up.



Cisco.com has this to say about the 402101 error:


-------- Error Message %PIX-4-402101: decaps: rec'd IPSEC packet has invalid spi for destaddr=dest_address, prot=protocol, spi=number



Explanation Received IPSec packet specifies a Security Parameters Index (SPI) that does not exist in SADB. This may be a temporary condition due to slight differences in aging of SAs between the IPSec peers, or it may be because the local SAs have been cleared. It may also be because of incorrect packets sent by the IPSec peer. This may also be an attack.



Recommended Action The peer may not acknowledge that the local SAs have been cleared. If a new connection is established from the local router, the two peers may then reestablish successfully. Otherwise, if the problem occurs for more than a brief period, either attempt to establish a new connection or contact the peer's administrator.



--------



If do a clear of the local SAs on the 1751, the tunnel comes right back up on next interesting traffic. This seems to be normal, but then the same issues above happens after a short while. I don't really understand what is meant by the last line in the recommended action: 'attempt to establish a new connection' ; this should be done automatically by the use of the crypto map.



The time on the router and PIX is identical, as they are pulling from the same local NTP server.



Anyone have any idea what could be wrong here?



tia



-tical-



In article , wrote: :I have a new DSL setup at a remote site using a 1751 router with IOS :12.3(14)T1 with a VPN tunnel back to a PIX 515e running Version 6.3(3). : While maintaining a continuous ping to the remote router from the :central office, I still see tunnel disconnects. The PIX reports the :following a couple of times before dropping the tunnel: :%PIX-4-402101: decaps: rec'd IPSEC packet has invalid spi for :destaddr=XXX.XXX.XXX.XXX, prot=esp, spi=0xnnnn1f4(nnnn8500)

DSL is not necessarily particularily stable. In particular if your DSL provider uses PPPoE with you having to configure the PPPoE username and password on the 1751, then the DSL provider is "allowed" to close the PPP session at any time, forcing a new login and potentially getting a new IP address.

How often does the problem occur? I've heard of DSL providers that force this kind of disconnect once a day, once a week, once a month, at random every few months... or never at all.

The DSL line -- is that coming in on a dedicated line or a phone line? If a phone line, then do all the phone outlets have the necessary splitters (full DSL) [not required for G.Lite "splitterless" DSL which has a lower bandwidth.] Is the data or phone line involved a new one, or an old line that might have wears and shorts -- i.e., is the line possibly "noisy" ? Are you near the limit of 4.2 km "as the wires fly" from the Central Office?

This particular DSL setup requires no PPPoE config; the DSL modem handles all of that. All I needed to config was an ethernet interface and the tunnel.

The problem occurs numerous times throughout the day, and the strange this is I can be running a continuous ping and not have any packet loss, and the tunnel will go down and up.

The DSL is coming in on a phone line that is shared through a DSL filter adapter with a fax machine. Initially I though that incoming faxes were causing the problem, but when comparing a fax report to the pix log, the faxes and disconnects don't match up. The phone line is not new, but the DSL provider went onsite and did a site survey and said there should not be a problem with providing the service.

-tical-

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required