- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: IPSec VPN tunnel with Fortinet
- 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
IPSec VPN tunnel with Fortinet
Hello,
R81.20 Take 92 trying to establish the tunnel with Fortinet. The requirement is to do NAT as well as per below:
Both 192.168.200.100 and 10.168.200.100 are in the Fortinet community encryption domain.
IKEv2
Phase 1
AES-254
SHA256
Group19
Phase 2
AES-254
SHA256
Group19
Had to select "One VPN tunnel per Gateway pair" to successfully (I think so) establish the tunnel, otherwise was getting "traffic selectors unacceptable" errors.
IKE IDs seem to be negotiated correctly: <10.168.200.100><192.168.200.100>
When trying to connect from 192.168.100.100 to 192.168.200.100 the access times out. I see no errors in the tracker (it hits the right NAT and access rules), but Fortinet side claims they never receive anything from 10.168.200.100. According to them the tunnel is up but no traffic is passing.
Tried to collect VPN debug logs - can only see "Create Child SA" and then immediately "Delete" events. I also double-checked for any network overlapping - no issues here.
Would appreciate any help!
- Labels:
-
NAT
-
Site to Site VPN
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Teddy_Brewski You have the Fortigate set for a universal tunnel (0.0.0.0/0, 0.0.0.0/0). When you set "pair of subnets" or "pair of hosts" on the Check Point side, the Check Point will propose a subset of the universal tunnel (say 192.168.100.100/32, 10.168.200.100/32). While Check Point and Cisco will accept a subset of the networks like this when receiving a proposal, Fortinet/Juniper/Palo Alto will not. The proposal must match EXACTLY on Fortinet which is why only "pair of Gateways" seems to be working for you. When the proposal does not match exactly, the Fortinet rejects it by simply dropping the Phase 2 proposal and not responding.
So you either need to go with the universal tunnel option for both sides, or painstakingly list out all the subnet/host combinations on the Fortinet end, and then ensure that the Check Point Phase 2 proposals EXACTLY match how the Fortinet is configured by configuring the subnet_for_range_and_peer directive in a *.def file.
March 27th with sessions for both the EMEA and Americas time zones
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You have to exclude the WAN IP from Encryption Community to make this work. If this is very new to you, open SR# with CP TAC to get this runing!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@G_W_Albrecht, thank you. Can this be done per community or this is the gateway change? I have ~20 VPN tunnels on this gateway without any issues (not with the same NAT rule though).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here is what I would do. Do debugs on both sides as below. I have fully working Fortigate VM thats licensed till April 4th that I connected to FortiSASE with valid real external IP address, so can test anything you need. Btw, I dont believe there is way to exclude external IP from the tunnel per community, but, I have no proof thats your issue so far.
CP debug:
vpn debug trunc
vpn debug ikeon
-try generate affected traffic
vpn debug ikeoff
Look for iked* and vpnd* in $FWDIR/log dir
Fortigate debug:
di de di
di debug app ike -1 (good for 30 mins)
di de en
leave like that and you will see bunch of messages
quit or ctrl+c to stop
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Better open SR# with CP TAC to get this runing! I wrote as i just had an issue with one of our partners concerning CP SMB to Fortinet VPN...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry, perhaps I misunderstood you, but none of the three IPs are public. 192.168.100.100 is my internal server, while 10.168.200.100 and 192.168.200.100 have been assigned to me by the Fortinet side -- all private.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For the reference, I also included some screenshots I took from Fortigate lab. I know it wont be same obviously, but hope it helps. Dont worry about network overlay ID number, thats not relevant here.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Teddy_Brewski You have the Fortigate set for a universal tunnel (0.0.0.0/0, 0.0.0.0/0). When you set "pair of subnets" or "pair of hosts" on the Check Point side, the Check Point will propose a subset of the universal tunnel (say 192.168.100.100/32, 10.168.200.100/32). While Check Point and Cisco will accept a subset of the networks like this when receiving a proposal, Fortinet/Juniper/Palo Alto will not. The proposal must match EXACTLY on Fortinet which is why only "pair of Gateways" seems to be working for you. When the proposal does not match exactly, the Fortinet rejects it by simply dropping the Phase 2 proposal and not responding.
So you either need to go with the universal tunnel option for both sides, or painstakingly list out all the subnet/host combinations on the Fortinet end, and then ensure that the Check Point Phase 2 proposals EXACTLY match how the Fortinet is configured by configuring the subnet_for_range_and_peer directive in a *.def file.
March 27th with sessions for both the EMEA and Americas time zones
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
They are running R81.20, using the granular encryption domain feature would be a better solution than messing with *.def files.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you @Timothy_Hall -- do you mean I need to have the tunnel working with "pair of subnets" or "pair of hosts"?
I noticed that there is an option:
Is this my encryption domain that can be adjusted per community? I tried to put the NAT address (10.168.200.100) there, and to change it to pair of hosts, but still get "traffic selectors unacceptable" errors.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That is one spot where you can set the encryption domain per community, I like to do it within the VPN community.
Your granular encryption domain should be:
- 192.168.100.0/24
- 10.168.200.100/32
You are getting the TS unacceptable because Fortinet is rejecting your proposal. Based on the diagram it sounds like you should be doing a tunnel sharing mode of host to host, because really, it's only these two IP addresses communicating:
- 10.168.200.100 (CheckPoint) and 192.168.200.100 (Fortinet)
It would help if the Fortinet side could provide a screenshot of their Phase 2 configuration, then we would really get to the bottom of this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
All makes sense. I know some customers may create FGT object with actual subnets, but then on Fortigate side, it would show as 0.0.0.0/0, like in one of my screenshots. Not sure if it works say if you were to set Fortigate interoperable object to empty group as vpn domain object, since I only do so with Azure/AWS.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Timothy_Hall, @CaseyB , @the_rock, @G_W_Albrecht -- many thanks for your input! I appreciated it very much.
Once I adjusted my encryption domain to match exactly what was advertised by Fortinet, the tunnel has established with "pair of hosts".
Thanks again!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Glad you got it working!
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you see the IKE IDs <10.168.200.100><192.168.200.100> in the logs, then you are using host to host. Gateway pair will show up as <IPv4 Universal Range><IPv4 Universal Range>.
The diagram mentions your encryption domain is 192.168.100.0/24, you are using the NAT address of 10.168.200.100/32, this needs to be in your encryption domain.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you. If I'm not wrong, host to host would be shown as "host: IP.address and host: IP.address". At least this is how it shows in one of my tunnels using host to host.
I have a tunnel with the similar configuration, Check Point to Check Point though, and the NAT address is not in my encryption domain -- seems to work.
Thank you anyways -- I will give it a try tomorrow!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That would make sense. Btw, just FYI, if you are using como of hosts/subnets, then tunnel mgmt should be set "per gateway" on CP tunnel setting side.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, it is, I couldn't make it work with other two -- the error message was "Traffic selectors unacceptable":
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Okay, I know why you see that. I know this may sound stupid what I will say now, but trust me, its NOT 🙂
Here is what Im referring to. On Fortigate side, make sure that multiple enc methods are not selected, ONLY what is being used, so say aes256 sha 256 and df group if needed.
In the old says of versions 5.x and 6.x, you would get multiple options there by default and that was fine, but in newer versions, 7.x.x, that is not the case.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unfortunately adding the NAT address in my encryption domain didn't help. I'm going to try to adjust the encryption domain per community.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That sounds like the next logical step.
