Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

PIX to Checkpoint VPN problem

I have site-to-site VPN setup between PIX 506E (my side) and Checkpoint NG 4.1 (customer side).

We are FTPing to a customer site to receive or to send files. FTP hosts on both sites are AS400 boxes. FTP runs as a batch job.

Everything seems to work fine but once a while (once, twice a day) my FTP sessions are dropped. It creates a havoc. Job which was dropped has to be reverify and resend. When it happens during a night hours pagers rings continously across the company.

What I see in a debug is that PIX is requesting sa renoegotiation (every 3600 seconds) but remote box (Checkpoint) is not responding. It is not communication problem but probably sa renegotiation problem.

Sometimes I receive the following debug message:

%PIX-4-402101: decaps: rec'd IPSEC packet has invalid spi for destaddr=, prot=esp, spi=0x749429be(-1104571276)

Another time I see on the PIX "sa created" message without seeing "sa request" message first. I assume that in such case remote Checkpoint requested sa negotion and he sent "sa request".

any suggestions how to fix this problem?

thank you and regards

New Member

Re: PIX to Checkpoint VPN problem

I will check the following:

1. How long does it take to complete your FTP batch jobs and I will set my IKE and IPSEC life times to be higher than that time.

2. Setting the IPSEC lifetime associatation to 1 hour might be very, very aggressive. Try evaluating the impact of someone decifying the encryption keys for each session to the value of the data. It will take at least 5000 hours to someone to break 3DES and a hash algorithm SHA-HMAC with group 2 DH.

3. Synchornize the Lifetime association on both devices to be the same.

Here is a break down of what you are experiencing:

1. %PIX-4-402101: decaps: rec'd IPSEC packet has invalid spi for destaddr=IP_addr, prot=protocol, spi=spi

Received IPSec packet specifies 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 becau se 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, e ither attempt to establish a new connection or contact the peer's administrator.

CreatePlease to create content