VPN - Check Point and Fortigate

[beneaton]

Hi all,

#Site A Check Point R80 (At the moment I can't confirm if R80.10,20,30..)
#Site B Fortigate

Reports of the VPN keep showing loads of errors with " 'Quick Mode Received Notification from Peer: invalid spi "

It's not every time, so with it being intermittent I have ensured both Sites have the same Encryption settings, and the Phase 1 and Phase 2 timers are definitely set to the same time/interval.

What else could be checked? Or what else do you guys who may have seen this before think it could be?

I don't have much more information at the moment, but I would like to arm myself with some potential solutions or scenarios to troubleshoot.

Thanks

[G_W_Albrecht · Accepted solution]

I would suggest sk108600: VPN Site-to-Site with 3rd party

[beneaton]

Thanks - I'll get Solution #7 attempted 1st of all.

[beneaton]

The suggestion most related to the error they're getting is to create a No-NAT rule. However in the VPN community in R80 you can opt to tick the option "Disable NAT within the VPN community" - Wouldn't this perform the same action?

Note: I've also suggested trying SHA256 instead of SHA1, and to not use PFS.

Thank you

[HeikoAnkenbrand]

Hi @beneaton,

Use following settings:

Phase 1:
- Main Mode (not aggressive mode)
- AES-256 / SHA256
- Use max. DH group 5 (not higher)

Phase 2
- Do not use PFS
- AES256 / SHA256

This always works with CP R80.30 latest JHF and Fortigate 5.4, 5.6, 6.0, 6.2.

[beneaton]

Hi Heiko,

Thanks for the reply.

PFS is set to Group 2 as well as the DH group in Phase 1. I'll ask them to test without PFS set (removed from both Sides).

Thanks again,
Ben

[Uri_Lewitus]

I remember handling a similar case in which this error came up and it turned out that the somehow the database contained 2 objects with the same IP. (VPN peer IP)

I know this is somewhat strange however worth checking..

HTH

Uri

[j_silva]

Hi Heiko

Do have some explaination for the reason to not check PFS ?

I have the same scenario, but in my case the vpn is established and when the user (behind the fortigate) try to access a server (behind the CP) the traffic is coming from the external interface and this traffic is dropped by antispoofing. I already configure a group to allow this network, but the traffic still coming from the external interface.

[JanVC]

you probably have another internal interface with antispoofing configured with too big networks

for example CP is expecting traffic from 10.0.0.0/8 to be coming from eth5 (internal interface), and now all of a sudden 10.100.0.0/24 is coming in via a VPN on the external interface
either eth5 is configured to broad for antispoofing or you need to configure exclusions on eth5

[j_silva]

Hi,

Thanks for your feedback.

The internal network was configured in "Specific Network" and due that the external interface was drop. I removed the network from the Specific Network and everything worked.

[Vincent_Bacher]

Hi,

CP receives that message from the FG?
Then you could do on the FG

diagnose debug reset
diagnose vpn ike log filter dst-addr4 <ext. IP of CP gw>
diagnose debug app ike -1
diagnose debug console timestamp enable
diagnose debug enable

after testing, disable and reset debugs

diagnose debug reset
diagnose debug disable

Cheers
Vincent

[Timothy_Hall]

Assuming you've already verified the SA Lifetimes, ensure that the Fortigate is not using a data lifesize or tunnel idle timer.  It sounds like the Fortigate is expiring the tunnel early for some reason.  Also make sure DPD is disabled on the Fortigate unless you have explicitly enabled it on the Check Point side.

Also be aware that during Quick Mode Phase 2 negotiations the Fortigate is just like Juniper in that it is very picky about subnets/Proxy-IDs it will accept.  The proposal must exactly match the subnets/Proxy-IDs configured on the Fortigate, unlike Cisco and Check Point it will refuse a proposal that is a subset of what is configured.