IOS Checkpoint VPN Issue

[stephen.stack]

Hi,

I am troubleshooting a VPN issue with a checkpoint at the moment, I am aware of the various issues i.e. supernetting issue etc..

Right now, i have a whole lot of IPSec SAs that are not functioning, and for one reason or another i cannot tear down the entire VPN. What i would like to do is tear down the dead/faulty IPSec SAs. Example below. Is it possible to do this?

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (10.1.3.65/255.255.255.255/0/0)
   remote ident (addr/mask/prot/port): (10.12.18.6/255.255.255.255/0/0)
   current_peer 1.1.1.1 port 500
     PERMIT, flags={}
    #pkts encaps: 1220154, #pkts encrypt: 1220154, #pkts digest: 1220154
    #pkts decaps: 1455516, #pkts decrypt: 1455516, #pkts verify: 1455516
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 10439, #recv errors 0

     local crypto endpt.: 2.2.2.2, remote crypto endpt.: 1.1.1.1
     path mtu 1500, ip mtu 1500
     current outbound spi: 0x0(0)

     inbound esp sas:

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

     outbound ah sas:

     outbound pcp sas:

On a slight aside, traffic hitting this SA are getting send errors on the SA and are therefore not bring sent. Probably because the SA is not established. But there is another SA further down which carries both Subnets where traffic not specified in more specific SAs above gets passed successfully . When traffic hits IPsec, is the traffic process sequentially? Or does that even make sense

Regards

Stephen

[Marcin Latosiewicz]

Stephen,

We cannot send a delete for a SA which is not active on our side (the one indicate is not).

If it was active you can clear it ...

ciscoasa# clear crypto ipsec sa entry 1.2.3.4 esp ?
  <0-ffffffff>  IPsec SA (inbound) SPI

send errors will be increasing most notable in a situation when traffic hit the ACL but the IPsec SA are not yet up.

In this particular case I would assume that the ASA is trying to bring up the tunnel in the background but it's failing phase 2 negotiation.

Honestly, I've read about chosing right entry in ACL a long time ago but remember it as being a bit more complex than just finding first or best match (at least on the scale of whole crypto map), so I can't answer this part of the your question.

Indeed any supernetting or overlap is going to make things work in a less predictable way.

Marcin

[stephen.stack]

Thanks for the Reply Marcin.

I asked about the processing order because of the number of 'dead' SAs that were still in the IPSec tunnel list. I got permission to tear down the VPN but it took a few commands to clear out all 'Dead' SAs.

cle cry sa map EXTRANET-VPN

cle crypto session local 89.202.154.101 remote 122.98.9.200

cle crypto sa peer 122.98.9.200

gen0rt03#cle cry isakmp ?

  <0-32766>  connection id of SA

If these build up again, i am going to have to attempt to resolve the various incompatibilities between IOS and Checkpoint for VPN, and i suspect it is the dreaded Checkpoint Supernetting issue.

Thanks again

Stephen

[Marcin Latosiewicz]

Stephen,

D'oh! I sent you information for ASA ... just because I was working on ASA just  second ago.

Clearing IPsec and ISAKMP SAs should be enough (or just clear cry session, as you've done)

Now if the SAs are still in DB but without active SPIs, there should be no problem on ASA side.

You can check "show crypto map" output to see if the information is populated correctly on our side, we see rarely problem with this.

What software are you running?

Marcin