PIX 515E VPN keep-alive failure

[pearson-jones]

I have an IPSec VPN between two PIX 515Es and most of the time it works fine. Every few days however the keep-alive fails with a debug error 713039 for no obvious reason, and then every time an attempt is made to re-establish the VPN the same error occurs. After rebooting the PIX the VPN establishes with no problem. The software version is 7.1(2). The following is an extract from the debug log at the time of the keep-alive failure

%PIX-7-715036 Group = 208.126.164.22, IP = 208.126.164.22, Sending keep-alive of type DPD R-U-THERE (seq number 0x394c97ff)

%PIX-7-715046 Group = 208.126.164.22, IP = 208.126.164.22, constructing blank hash payload

%PIX-7-715046 Group = 208.126.164.22, IP = 208.126.164.22, constructing qm hash payload

%PIX-7-713236 IP = 208.126.164.22, IKE_DECODE SENDING Message (msgid=576b1de0) with payloads : HDR + HASH (8) + NOTIFY (11) + NONE (0) total length : 84

%PIX-7-713039 Group = 208.126.164.22, IP = 208.126.164.22, Send failure: Bytes (84), Peer: 208.126.164.22

%PIX-7-713906 Group = 208.126.164.22, IP = 208.126.164.22, Can't send request after processing!

This debug message is listed as an internal software error. Is anyone aware of a problem like this in ver. 7.1(2) of the software?

[r.docuyanan]

Hi Jones,

Have you tried resetting your ipsec peer ?

clear crypto isakmp sa command

do you have pfs seet on your peer?

as per cisco "IKE negotiations with a remote peer can hang when a PIX firewall has numerous tunnels that

originate from the PIX firewall and terminate on a single remote peer. This problem occurs when PFS

is not enabled, and the local peer requests many simultaneous rekey requests. If this problem occurs,

the IKE SA does not recover until it times out or until you manually clear it with the clear [crypto]

isakmp sa command. PIX firewall units configured with many tunnels to many peers or many clients

that share the same tunnel are not affected by this problem. If your configuration is affected, enable

PFS with the crypto map mapname seqnum set pfs command."

Check both PIX if they have pfs enabled or not

[pearson-jones]

Thanks for your reply. I have tried clearing all SAs on the peer with the clear isakmp sa command but this didn't resolve the problem. Also PFS is not enabled on either the local or remote PIX.

The configuration is as follows: We have a PIX 515E in Leeds running software version 6.3(1) and this has two IPSec tunnels, one to a PIX 501 in York and one to a second PIX 515E in Sheffield running software version 7.1(2). Everything works fine for days (sometimes over a week) with keep-alives every 10 secs and key exchanges every 24 hours, and then without warning the Sheffield PIX515E will fail to send a keep-alive as seen in the debug log in the original post. After a couple more attempts the Sheffield PIX reports that it has lost connection with Leeds and deletes the SA. It then constructs a new IKE payload to re-create the SA but this also fails with an error 713039 Send Failure. It then retries continuously to re-create the SA but each time the same debug error is logged. However, despite the Send Failure messages, the Leeds firewall receives every one of the SA setup requests, accepts them and replies with a key acquire message to Sheffield. The Sheffield PIX processes the key acquire messages but fails them because it has no match as it believes the original was never sent.

The net effect of all this is that a 'show isakmp sa' on the leeds PIX shows numerous SAs with Sheffield (often 60 to 70) but none of them active, and the number changes constantly as new requests are received from Sheffield on the one hand while the Leeds 'reaper' times them out on the other. Performing a 'clear isakmp sa' on the Leeds PIX does clear all the SAs briefly, but these just grow again as the Sheffield PIX continues to send new requests in the mistaken belief that they failed to send.

Currently the only resolution I have to this is to reboot the Sheffield PIX after which everything works fine again for another few days.

I hope this makes sense. The debug error 713039 is documented by Cisco as 'This message appears when an internal software error has occurred and the ISAKMP packet could not be transmitted'