How to deeply delete any IKE/IPsec information linked to a Peer

[CheckPointerXL]

Hi all,

today i tried to move, on customer side, a VPN with thirdy-party from their Cisco to their Check point, scenario:

Move from: Third Party---VPN---Cisco---clear traffic--CheckPoint

Move to: Third Party---VPN---CheckPoint

Spent hours in troubleshooting, then we decided to rollback from check point to Cisco, but some traffic continued to not work.... so i discovered that a lot of test was probably invalidate by the following behavoir:

when rollback was decided, i removed on mgmt the CheckPoint gateway from the community, disabled all rules... basically deleted everything, only Community with remote peer left on management.

Installed, vpn tunnel down on CheckPoint and UP again with cisco, but still some traffic, originated behind check point and routed to the Cisco for encryption, was not working.

On FW, after tunnel disruption was done, i  continued to have the following output despite Community was destroyed:

Not working traffic by fw ctl zdebug + drop | grep IPnotResponding:

Then, roughly after 1 hour, when the above SA with "No outbound SA" disappeared, no more drop on zdebug and traffic started to work again. But now i don't wanna know WHY this behavoir... (but it should be discussed too i think...)

i'm pretty sure the same behavoir created to me a lot of problem in the past, especially during a change in configuration on P2.

So i'm going to the question, vpn tu (7) seems to not work properly for such cases, how can i DEEPLY clear any IKE/IPSec SA associated to a vpn? i tried to find a way to delete the MSA/MSPI by his identifier but no luck, any suggestion ???

[the_rock]

Good question...I checked with vpn tu tlist -h command, but cant see option for delete. I also typed vpn and when you hit enter, it gives bunch of stuff, but nothing really similar to what you need. Lets see if someone else may know.

Andy

[Danny]

As this tool of mine shows, vpn tu del PEER_IP might help.

[CheckPointerXL]

hi danny, i'm not sure but i think that vpn tu del PEER_IP is a "shortcut" to the option 5 on vpn tu... and option 5 is a "lighter" version of option 7 (it preserve IKE SA)....so it should not help

[CheckPointerXL]

anyway, I THINK that any attempt to delete the SA it will fail because in such cases, there is "NO outbound SA" and here  we are trying to delete an MSA/MSPI, that is something different:

• MSA - "Meta SA".

  • Contains:
    
    • Methods
    • Encapsulation scheme (ESP, AH, UDP)
    • Encryption algorithm
    • Data integrity algorithm
    • Peer identity
    • Peer address
    • User name (for Remote Access client)
    • Intended use (IPsec IDs)
    • Access to Current usable SA (outbound only)
  • MSA is bi-directional.
  • Inbound SAs point to the MSA.
  • The MSA points to an outbound SA.
  • When SAs are rekeyed and replaced, the MSA is not. It is just updated.
  • An encrypted connection is marked with an MSPI (handle for the MSA).

MSPI - "Meta SPI" = peer + methods + IDs.

• MSPI is not a standard concept and exists only in Check Point VPN kernel.
• MSPI is actually a tunnel identifier. It is a local counter that uniquely identifies a tunnel on the given machine.
  In cluster topology it needs to be translated from the MSPI of peer cluster member to the local MSPI.
• MSPI is an index to the MSA (Meta SA), which contains fields common to all SAs with the same peer, methods, IDs, where:
  
  • Peer - peer gateway IP address
  • Methods - per rule (community) parameters
  • IDs - client/server or their containing subnets
• When a new IPsec tunnel is established, a new MSPI is created by, it get the next free MSPI number, and the MSPI counter is increased.
• When an IPsec tunnel is closed, the MSPI counter is decreased.

that is probably the root cause of the trafffic problem, but, coming back to the thread question, this is why any attempt to delete that entry will fail with any "delete SA" command.... of course these are only my assumptions, need a vpn king here to be sure 🙂 

[PhoneBoy]

Clearly this information is stored in one or more table entries.
The trick is figuring out which one (using fw tab).
From there, you can delete the entries with fw tab -x (I believe).

[anstelios]

Hello Phoneboy,

Don't you think there should be an easier way to do this?
Having traffic outages after deleting all related VPN configuration because the CP firewall still has some entries in some tables that you need to dig deep and if lucky you may find it(probably not).. 

CP needs to understand that customers are getting less and less tolerant to this kind of quirks..

[CheckPointerXL]

100% agree

Not only customers, administrators like us too...

[PhoneBoy]

It's possible this particular issue is not known or not encountered often enough.
However, I tend to think vpn tu should either offer an option for this or do it as part of one of the existing options.
I'll ask around. 

I believe the correct table to find this in (per https://support.checkpoint.com/results/sk/sk104760) is called meta_sas.
You can use fw tab -x to delete the relevant entry in the connections table.
Other tables are also listed there. 

[JozkoMrkvicka]

vpn tu (option 7) works perfectly fine in case both peers are Check Point gateways while the "vpn tu" command is executed AT THE SAME TIME on both Check Point peers.

Another option can be to use SAM rule on Check Point gateway to reject connection to/from peer.

[CheckPointerXL]

the problem is getting critical with other customer

we converted a problematic vpn policy based in vpn route based. Despite the tunnel was resetted, "No outbound SA" still there and i clearly see with my eyes on ASA side that check point keep tried to negotiate some subnets !! 

At that time we was on route-based, so empty group + one vpn per gateway pair

Need absolutely to underestand how to clean that f****g cache

[CheckPointerXL]

How can i clean all that P1 entries for a VPN Peer?

tried: vpn tu (7), vpn accel off, removed gateway from community for 10minutes....

[PhoneBoy]

When I asked about this problem previously, I was told that this issue needs to be handled via the TAC.
It is likely some sort of bug that is causing this.

[Timothy_Hall]

I'd suspect that the withdrawal of IKE negotiation duties from vpnd and re-implementation of that into the new iked daemon in R81.10+ may have something to do with these problems, and this transition may have broken something in how vpn tu interacts with it.  Something perhaps for R&D to look into.  @CheckPointerXL I assume you are running at least R81.10 and iked is running on your gateway?

[CheckPointerXL]

correct, it seems that compulsively doing vpn tu->optin 7-ip peer it works.... maybe it's a case, but it worked last two times (only for Phase2)