topic Re: Route-based vpn with FortiGate not passing traffic - “no MSPI for MSA” in Firewall and Security Management

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

SteveW — Thu, 11 Dec 2025 16:47:32 GMT

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

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

the_rock — Thu, 11 Dec 2025 16:49:32 GMT

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

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

Vincent_Bacher — Thu, 11 Dec 2025 18:35:51 GMT

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?

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

the_rock — Thu, 11 Dec 2025 18:51:06 GMT

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

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

Vincent_Bacher — Thu, 11 Dec 2025 18:55:20 GMT

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.

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

the_rock — Thu, 11 Dec 2025 18:57:45 GMT

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

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

Vincent_Bacher — Thu, 11 Dec 2025 19:07:37 GMT

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/Topics-FWG/Kernel-Debug/Kernel-Debug-Filters.htm

addendum 2

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

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

Vincent_Bacher — Thu, 11 Dec 2025 19:06:14 GMT

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

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

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

the_rock — Thu, 11 Dec 2025 19:06:52 GMT

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

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

Vincent_Bacher — Thu, 11 Dec 2025 19:09:55 GMT

Hopefully

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

SteveW — Fri, 12 Dec 2025 09:16:15 GMT

Hi Andy, using numbered VTIs as recommended by TAC

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

the_rock — Fri, 12 Dec 2025 11:51:31 GMT

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

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

the_rock — Fri, 12 Dec 2025 14:16:41 GMT

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

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

SteveW — Mon, 16 Feb 2026 14:12:16 GMT

TAC didn't offer much assistance, just said it was a configuration mismatch error and closed the case.

Tried many things but could not solve the narrowing /eclipsed tunnel on the Check Point so asked the third-party to change the Fortigate traffic selectors to universal. This fixed the problem with narrow / eclipsed and also stopped the "no MSPI for MSA" error.

fw crl zdebug + drop now shows that traffic is no longer being dropped and the FortiGate side have confirmed that the traffic is arriving. However, the traffic is only passing in one direction - from Check Point to FortiGate.

I think this may be because the Check Point is using a Numbered vti, which is the recommended option and the peer won't have a corresponding 169.254.x.y address configured.

I am checking with the remote side if the FortiGate can be configured with a 'local IP' to match my Numbered vti as the articles I have read point to this being the problem. If there are any FortiGate wizards out there your comments would be appreciated.

Thanks

Steve

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

the_rock — Fri, 13 Feb 2026 16:49:20 GMT

Can you try vpn domains as empty group and then tunnel mgmt permanent tunnels and per gateway setting?

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

simonemantovani — Sat, 14 Feb 2026 21:46:51 GMT

Hello

in any case, if you configure a route based vpn with numbered VTI, you should:

Create the VPNT interfaces. Set the ID, and the peer name (this is the name of the interoperable device you'll configure in the next steps). Define an IP address for Firewall 1 and for Firewall 2 (in smartconsole you'll configure the cluster IP used as a next hop by the Fortigate's routing configuration).
Configure routing for remote networks (the networks behind the Fortigate) using as a next hop the IP address assigned to the Fortigate's VTI.
In Smartconsole , update the topology of your Check Point adding the VPNT interfaces and configuring cluster IP for this interface.
Then create the interoperable device (fortigate).
configure the VPN community, the encryption domain for your Check Point cluster and the Fortigate should be an empty group.
In the VPN community, configure Tunnel Management with the one tunnel per gateway option selected (do not enable Permament Tunnel because is not supported by Fortigate).
Configure access policy.

I'm sure that you've already configured your Check Point in this way, obviously Fortigate must be configured in a similar way, by configuring as encryption domains the 0.0.0.0/0.0.0.0 (on both local and remote network) and also the routing as configured on Check Point.

Usually these are the steps you need to follow to configure the route based vpn between Check Point and a 3rd party device.

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

the_rock — Sat, 14 Feb 2026 22:06:33 GMT

I made post about it 2 years ago.

https://community.checkpoint.com/t5/Firewall-and-Security-Management/Route-based-VPN-tunnel-to-Azure/m-p/206179/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufExTTjlYV1FXMUlGQVNMfDIwNjE3OXxTVUJTQ1JJUFRJT05TfGhL#M38950

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

SteveW — Mon, 16 Feb 2026 14:27:49 GMT

Hi Andy,

I already have empty groups for the vpn domains on both sides and also Tunnel per gateway pair. I have tried permanent tunnel and non-permanent and the result is the same. As Simone points out, the permanent tunnel is specific to Check Point so is ignored by the FortiGate.
I used your post from 2 years ago as a reference but went with Numbered vti rather than Unnumbered because that was the recommendation.

I have vpns working successfully with Azure off the same security gateway but what was used there has not helped with getting the FortiGate vpn working.

Thanks for your input and based on the results I'm getting I think I'm getting closer to resolving it.

Thanks,

Steve

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

the_rock — Mon, 16 Feb 2026 14:30:03 GMT

Hey Steve,

If you are allowed to do remote, Im fairly confident we could make this work. I had done permanent tunnels with Fortigate dozen times (at least), always worked fine.

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

SteveW — Mon, 16 Feb 2026 14:54:02 GMT

Hello Simone,

Thanks for confirming the steps needed to create the vpn. Those are the actions I had taken and confirms that my Check Point peer is configured correctly.

For the numbered vti I have used 169.254.x.83 and 169.254.x.84 for the cluster members and 169.254.x.82 for the cluster vip. The next-hop is 169.254.x.81 and this has been configured in the static route in the routing table for each member.

I thought the 169.254.x.y addresses were significant only locally but I think the FortiGate needs to be configured with169.254.x.82 as the next-hop so that it can send traffic to my Check Point. This is the part I am unsure about because I'm not familiar with the FortiGate setup and if it can support a corresponding 'internal IP' as the next-hop back to me. I'm waiting for the third-party to get back to me.

Thanks,

Steve