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

[SteveW]

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?

[SteveW]

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

[SteveW]

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 

[the_rock]

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

[simonemantovani]

Hello

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

1. 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).
2. Configure routing for remote networks (the networks behind the Fortigate) using as a next hop the IP address assigned to the Fortigate's VTI.
3. In Smartconsole , update the topology of your Check Point adding the VPNT interfaces and configuring cluster IP for this interface.
4. Then create the interoperable device (fortigate).
5. configure the VPN community, the encryption domain for your Check Point cluster and the Fortigate should be an empty group.
6. 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).
7. 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.

[the_rock]

I made post about it 2 years ago.

https://community.checkpoint.com/t5/Firewall-and-Security-Management/Route-based-VPN-tunnel-to-Azure...

[SteveW]

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

[the_rock]

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.

[SteveW]

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

[simonemantovani]

Hello

to do an example, you could assign the IP addresses like this way:

FW1 - 169.254.x.83/32

FW2 - 169.254.x.84/32

FW CLUSTER - 169.254.x.82/32

FORTIGATE - 169.254.x.81/32

Next hop for the static routes on Check Point: 169.254.x.81

Next hop for the static routes on Fortigate: 169.254.x.82

When the VPN is UP, and it's permitted you should be able to ping the Fortigate IP address from the Check Point.

[SteveW]

Hello Simone, thanks for confirming the settings. As soon as I hear back from the FortiGate admin I will ask them to give this a try. The Check Point is already configured as above.

Best regards,

Steve

[Vincent_Bacher]

You are asking if the Forti can use numbered VPN interfaces? Yes, it can.

According to 40net admin guide it should look like this.

config vpn ipsec phase1-interface
    edit vpn-2-cp
        set interface "wan"
        set dpd enable
        set local-gw 1.2.3.4
        set dhgrp 2
        set proposal aes128-sha1
        set keylife 28800
        set remote-gw 4.3.2.1
        set psksecret TheEmpireStrikesBack
        set dpd-retryinterval 10
    next
end

config vpn ipsec phase2-interface
    edit "vpn-2-cp"
        set phase1name "vpn-2-cp"
        set proposal aes128-sha1
        set dhgrp 2
        set pfs enable
        set keylifeseconds 3600
    next
end

config system interface
    edit "vpn-2-cp"
        set vdom "root"
        set ip 169.254.x.81 255.255.255.255
        set allowaccess ping
        set type tunnel
        set tcp-mss 1379
        set remote-ip 169.254.x.82
         set interface "wan"
    next
end

Did not test exactly this settings but in general this is what i configured several times between a 40 and any other vendor when a routing protocol was required in between.

[SteveW]

Hi Vincent,

Thank you for confirming the 40 can work with numbered vti and supplying the example configs. I will let everyone know the result when this has been tried on the remote peer.

Best regards,

Steve 

[the_rock]

Im not nearly as expert in Fortigates like you are VInce, but yes, that looks familiar. I had done few route based tunnels with Fortigates that way.