- CheckMates
- :
- Products
- :
- General Topics
- :
- VPN - Check Point and Fortigate
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would suggest sk108600: VPN Site-to-Site with 3rd party
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would suggest sk108600: VPN Site-to-Site with 3rd party
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
now available at maxpowerfirewalls.com