Command to permanently delete ike+ipsec SAs for specific vpn tunnel

[the_rock]

Hey guys,

Im trying to figure out if there is a command that anyone knows that would permently delete ike and ipsec SAs for specific tunnel. Lets pretend, for argument's sake that peer IP is 20.21.22.23. Customer tried de-associating the tunnel by running vpn tu and then choosing to delete ike+ipsec sas option, also vpn tu list del command, no luck, always shows same ID number for security association.

I found few posts about this and in one, Tim Hall menmtioned vpn shell command, we also tried few variations of that, but no joy.

I had a call with T3 guy from DTAC about different vpn issue for another client and asked him this, but he said if neither of methods I mentioned worked, he believes deleting vpn tables from the gateway associated with the tunnel would help, but said the process for that might be somewhat cumbersome, so I did not inquire further.

We just need simple command that would accomplish this.

If anyone has an idea, please be free to share.

Best and thanks as always!

Andy

[PhoneBoy]

If vpn tu can’t find the tunnel, it’s a bug (or so I’ve been told by R&D).
It’s definitely not the first time this issue has been reported on CheckMates.

[the_rock]

Hey @PhoneBoy , it does find it and it looks like ike and ipsec sa's were deleted, but they are actually not.

Andy

[JozkoMrkvicka]

You can also use old-style SmartView Monitor where you can reset specific tunnel.

As very, very last resort:

How to manually delete an entry from the Connections Table (check also this thread by @Kaspars_Zibarts ).

[the_rock]

SV monitor was actually the first thing they tried. I think thats what TAC guy may had been referring to as well (entry from connections table), but he was not sure how to even find one related to that vpn tunnel...if you have an idea, please be free to share.

Best,

Andy

[the_rock]

Found another post where you mentioned saml rule, so let me give that option to the customer and see if that works.

Will keep you posted. That actually makes lots of sense to me.

Andy

[CaseyB]

I ran into a production outage due to this very same issue last week, it would be great if Check Point could get this resolved. Fingers crossed for R82 since a lot of VPN work is being done in that version. This is the guidance I've been given for this issue:

1. Reset tunnel from SmartView Monitor GUI
2. Reset tunnel from "vpn tu" CLI
3. Implement the following SAM blocks:
   • Traffic where the source is the Check Point public IP and the destination is the peer gateway IP;
   • Traffic where the source is the peer gateway IP and the destination is the Check Point public IP;
   • Traffic where the source is the subnet behind the Check Point and the destination is the subnet behind the peer gateway;
   • Traffic where the source is the subnet behind the peer gateway and the destination is the subnet behind the Check Point.

The SAM rules would be the last option when #1/2 fail.

[the_rock]

Will relay to the customer, thanks so much! Will keep you posted.

Andy

[the_rock]

Just tried, no luck. We even did cluster failover, same issue. They will ask guy on the other side to flip the tunnel, so lets see if that does it.

Andy

[Lesley]

What about to make a temp drop / reject rule for the public IP of the other side? 

So block the source with a rule and a rule for dst

After drop rule, clear tunnel with vpn tu and see what happens? 

Maybe tweak the timers a bit on the VPN community to smaller window so you dont have to wait a hour

[the_rock]

Tried that yesterday, no joy.

Best,

Andy

[CaseyB]

How long are the Phase2 timers for this tunnel?

[the_rock]

Its default ones...one day for phase1 and 60 mins for phase 2

Andy

[the_rock · Accepted solution]

Issue was fixed...we are not sure if resetting tunnel did it on the other side or also fact we did failover, or both, but good now.

Best,

Andy