Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
beneaton
Contributor
Jump to solution

VPN - Check Point and Fortigate

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

0 Kudos
1 Solution

Accepted Solutions
G_W_Albrecht
Legend
Legend

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

CCSE CCTE CCSM SMB Specialist

View solution in original post

11 Replies
G_W_Albrecht
Legend
Legend

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

CCSE CCTE CCSM SMB Specialist
beneaton
Contributor
Thanks - I'll get Solution #7 attempted 1st of all.
0 Kudos
beneaton
Contributor

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

0 Kudos
HeikoAnkenbrand
Champion Champion
Champion

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.

 

➜ CCSM Elite, CCME, CCTE
beneaton
Contributor
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
0 Kudos
Uri_Lewitus
Employee
Employee

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

0 Kudos
j_silva
Contributor

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.

0 Kudos
JanVC
Collaborator

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

0 Kudos
j_silva
Contributor

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.

0 Kudos
Vincent_Bacher
Advisor
Advisor

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

and now to something completely different - CCVS, CCAS, CCTE, CCCS, CCSM elite
0 Kudos
Timothy_Hall
Champion
Champion

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.

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events