IPSec VPN tunnel with Fortinet

[Teddy_Brewski]

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!

[G_W_Albrecht]

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!

[Teddy_Brewski]

@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).

[the_rock]

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

[G_W_Albrecht]

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...

[Teddy_Brewski]

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. 

[the_rock]

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

[Timothy_Hall]

@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.

[CaseyB]

They are running R81.20, using the granular encryption domain feature would be a better solution than messing with *.def files.

[CaseyB]

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.

[Teddy_Brewski]

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!

[the_rock]

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

[Teddy_Brewski]

Yes, it is, I couldn't make it work with other two -- the error message was "Traffic selectors unacceptable":

[the_rock]

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