Problem with ASA and Check Point VPN tunnel - traffic randomly stops passing traffic

[baskervi]

We have an ASA 5510 running 8.2(5) that has multiple VPN peers configured. One goes to a vendor who uses a Check Point firewall, and this tunnel drops randomly throughout the day, and we have to reset the tunnel to get it back up. If you do a "sh cryp isa sa", the peer is MM_ACTIVE. There are 6 lines for the access list that is tied to the tunnel. Some of these show incrementing traffic levels, but there usually are a couple that show the following:

      #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

The tunnel had been passing traffic, and packets were encypted and decrypted just minutes before. If I type "clear cryp isa sa <IP>", the packets start incrementing for this tunnel again. If I do a packet capture, I see the packets showing up on the ASA, but the don't appear to be entering the tunnel. I've disabled phase 1 lifetime keepalive using " isakmp keepalive disable" for this tunnel because this entry was in the debug:

May 11 20:59:29 [IKEv1]: IP = x.x.31.148, Keep-alives configured on but peer does not support keep-alives (type = None)

This doesn't help. I've also tried to adjust the phase 2 lifetime, but that hasn't helped either. Both ends of the tunnel have hosts defined for the interesting traffic, and I've read in several forums that the Check Point may try to use the subnet. However, I don't see any error messages on the ASA where the Check Point is trying to negotiate a network block. 

I also ran across the command "sysopt connection preserve-vpn-flows" to enable the ASA to retain the TCP state table between negotiations.

It's been difficult trying to get the other end on the line to debug because they are half way around the world, and they are very slow to assist us. I've found a lot of information in the various forums, but so far, nothing has helped. Does anyone have an idea? Thanks

[Edwin Matos]

Are any of the devices behind NAT? I had a situation on where I needed to setup the LOCAL ID / REMOTE ID on a Cryberoam appliance since my ASA was behind a NAT.

Another thing that I might look into it is the DPD ( Dead Peer Detection ) is active or supported on Checkpoint. On Phase 1 we know lifetime will negotiate to the lower time on Cisco but not sure on CheckPoint side. If I were you I would try to map each lifetime to the same amount of seconds or byte on both appliance.

A debug from the CheckPoint device will bring some light as well.

[baskervi]

I'm not sure about the other side, but the ASA is not NATed, although it performs NATing for hosts behind it. 

I'll check into DPD for Check Point. Regarding setting the lifetimes, we've requested this be done, but it doesn't affect the debug on our end.

I'll request they send us some debugging information.

Thanks for your input, and I'll follow up as soon as I have some more details.

[baskervi]

Just to test, I disabled the phase 1 lifetime, but that still doesn't help. 

I see the remote end sending a DPD R-U-THERE, and we've confirmed the phase 1 and 2 lifetimes are set the same, but the connection frequently stops passing traffic. 

I found several sites that had what appears to be an identical problem, and there is a Check Point command that seems to fix the problem in many cases: "ckp_regedit -a SOFTWARE/CheckPoint/VPN1 DontDelIpsecSPI_OnP1Del -n 1", followed by cpstop and cpstart. Unfortunately, the remote end simply isn't willing to make any changes, since they are having not problems with any other tunnels. Unfortunately, we're the only one with an ASA. They are also not responsive for sending us debug information, so it makes it difficult on our end. 

[mikej4521]

Hi,

Did you managed to solve this issue ?

I'm facing the same issue.

Regards.

[baskervi]

I apologize for never answering. I was going through some old email and ran across this. Unfortunately, no. We spent quite a bit of time changing settings on our end as the other end refused to make any changes. This was our only Checkpoint VPN endpoint we were connecting to, and we were the only ASA they were connecting to. Neither side had any problems with any other tunnels. We're still resetting the tunnel as needed.

[salman abid]

you better open TAC at both ends and take their advise on this issue

[Abaji Rawool]

For Cisco TAC case you can collect following debugs at the time of issue on ASA

debug crypro cond peer <peer ip>

debug cry isa 127

debug cry ips 127

run the packet tracer and collect the debugs

To stop the debugs "undebug all"

HTH

Abaji.

[j.pattinson]

I found the following recommendation also to support the use of the

sysopt connection preserve-vpn-flows

https://gsmaclean.com/?p=51

[Abaji Rawool]

Hi,

At the time of issue, please run packet tracer command for interesting traffic on the ASA and see if it is correctly encrypting it

http://www.cisco.com/c/en/us/td/docs/security/asa/asa80/command/reference/cmd_ref/p.html#wp1878788

Ideally when everything is ok, you should see encrypt ALLOW in VPN phase. If not then we need to debug it further.

HTH,

Abaji.

[baskervi]

Abaji, thanks for the response. When the tunnel is not functioning, the VPN phase has a result of DROP:

Phase: 9

Type: VPN

Subtype: encrypt

Result: DROP

Config:

Additional Information:

Forward Flow based lookup yields rule:

out id=0xd86234d8, priority=70, domain=encrypt, deny=false

        hits=21802, user_data=0x0, cs_id=0xd86176c0, reverse, flags=0x0, protocol=0

        src ip=x.x.118.31, mask=255.255.255.255, port=0

        dst ip=10.7.2.138, mask=255.255.255.255, port=0, dscp=0x0

If we do "clear cryp isa sa <IP>" and force the tunnel to renegotiate, it's back up and running. This is shortly after clearing the tunnel with no changes made to the configuration:

Phase: 9
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0xd8b17dc0, priority=70, domain=encrypt, deny=false
        hits=4, user_data=0xdc33b5c, cs_id=0xd86176c0, reverse, flags=0x0, protocol=0
        src ip=x.x.118.31, mask=255.255.255.255, port=0
        dst ip=10.7.2.138, mask=255.255.255.255, port=0, dscp=0x0

So there is a problem, but besides the DENY/ALLOW, there aren't many differences except the user_data=0 when it's not working. Do you have any additional thoughts?  The tunnel may drop once to several times per day, and we're not finding any rhyme or reason for this.

Thank you. 

[baskervi]

The tunnel just dropped again, and we're seeing something else with the packet-trace:

Phase: 9
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:

Result:
input-interface: DMZ2
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule