Route-based vpn with FortiGate not passing traffic - “no MSPI for MSA”

[Stephen_Ware]

Hi All,

I have a route-based vpn between a Check Point cluster (R81.20 Take 113) and a FortiGate. The vpn establishes and vpn tu tlist shows correct traffic selectors but tunnel is ‘narrowed’ and traffic from the remote subnet does not arrive.

My TS: 10.53.25.160/28              Peer TS: 192.168.5.0/28            

When the local peer sends outbound traffic the Check Point creates an additional tunnel with traffic selectors 0.0.0.0/0 on both side and this tunnel shows as ‘eclipsed’. Logs show outbound traffic is encrypted for the vpn and hits the correct outbound NAT rule translating it to a 10.53.25.x address.

fw ctl zdebug + drop | grep 192.168.5.x   shows outbound traffic being dropped with “no MSPI for MSA”.

The FortiGate peer then immediately sends a request to delete the SA –

“Informational exchange: Received delete IPsec SA request”

but the eclipsed tunnel persists until it eventually ages out.

The behaviour of the narrow and eclipsed tunnels is as described in sk166417

There are no overlapping addresses in the encryption domains and other route-based vpns on the Check Point with AWS are working correctly.

Many combinations have been tried for the encryption domains

• empty domains on one, other and both sides
• subnets on one, other and both sides
• individual IP addresses on one, other and both sides – including with and without the physical IP addresses of the servers

One tunnel per pair of hosts - does not work and causes repeated failed IKE negotiations

One tunnel per subnet pair – does not work, same result

One tunnel per gateway pair – the only option that works

Any suggestions?

Thank you

[the_rock]

Technically, one tunnel per gateway pair sounds like a right option here. Are you using numbered or unnumbered VTIs?

[Stephen_Ware]

Hi Andy, using numbered VTIs as recommended by TAC

[the_rock]

That should be fine. I would do debug I mentioned and see what you get.

[the_rock]

Maybe try Fortigate debug first, see if it gives any more details.

[Vincent_Bacher]

There’s an SK for older versions describing exactly this error, and while it says it’s fixed from R81 onward… who’s to say it didn’t sneak back in with a newer release?

[the_rock]

Yea...who knows. Might be hard to say without doing debugs.

[Vincent_Bacher]

So we agree that (kernel) debugging could be done here.
Unfortunately, I don't have the commands in my head, but a Tac case should help.

[the_rock]

I would start with below:

CP:

vpn debug trunc

vpn debug ikeon

-generate traffic

vpn debug ikeoff

fw ctl debug 0

-check for iked and vpnd* files in $FWDIR/log dir

FGT:

di de di

di de app ike -1

di de en

-generate traffic

-check for messages that print on the screen

[Vincent_Bacher]

Exactly that would be the first steps.

Here you can find kernel debugging as well. Not looked at the correct release but the command should be the same:

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_NextGenSecurityGateway_Guide/Topic...

addendum 2

first step im 40et should be diagnose debug reset to not get any unwanted debugs in case anything is already set

[the_rock]

Hopefully, they would not need to run kernel debug...

[Vincent_Bacher]

Hopefully 

[Vincent_Bacher]

Addendum: to look at the vpn debug trunc output you may use the good old ikeview tool

https://support.checkpoint.com/results/sk/sk30994