Site to Site VPN with Multiple Fortigate firewall via Hostname method (DDNS)

[Darren_Phang]

Hi Guys,

Although CP & FG IPSEC VPN Tunnel monitor show that the tunnel is up but the traffic couldn't transmit over the vpn tunnel. I can confirm that the encryption details and pre-share secret of both sites are identical.  I'm using CP1470 with the latest firmware R77.20.87 and the peers are different Fortigate models. So now my question is whether CP support site to site VPN with FG firewalls with the configuration below especially hostname method over pre-share secret? 

VPN site configuration:

Connection Type: Hostname (xxx.dyndns.org)

Pre-share Secret 

Encryption method: IKEv1 (main mode)

Disable NAT for this site (checked)

Access Policy has been configured (bi-directional)

Manual No NAT policy also configured

Local encryption domain has been defined 

Tunnel Health Monitoring (DPD)

Regards,

Darren

[Timothy_Hall]

I assume you are trying to initiate the VPN from the Check Point side to the Fortinet and it is not working, correct?  Reset the VPN tunnel and have the Fortinet initiate the VPN tunnel to you and send some test traffic in your direction.  If that works you need to ensure your local and remote VPN domain definitions match the Fortinet precisely, as the Fortinet is very picky about what subnets/Proxy-IDs it will accept when your end is the initiator.  See my post here:

https://community.checkpoint.com/t5/General-Topics/IPsec-Checkpoint-R80-10-and-Fortinet-issue-Only-t...

[Darren_Phang]

Hi Timothy,

Yes, you're right. I'm trying to initiate the VPN from CP to FG since HQ need to centrally access to all the branches to get the information but either FG nor CP is working in this case.

From the ike debug, it shows that phase 1 negotiation is successfully with 6 main mode packets shown but in phase 2 negotiation, CP is not responding to FG packets. In regards to the VPN encryption domain, I can confirm that both local and remote encryption domains are identical.

[Timothy_Hall]

Are you sure it is the Check Point that is not responding?  In my experience the Check Point side will always send back some kind of negative acknowledgement if it is proposed something it doesn't like by the peer.  However on the other hand, a Fortinet will simply discard a received Quick Mode (QM) proposal it doesn't like and not respond to it at all even if Phase 1 is already completed.  The only exception might be a mismatched Peer ID, but that is pretty unlikely with IKEv1.

Look at both the local & remote subnets/masks in ikeview being proposed in QM Packet 1 by the Check Point, BOTH must EXACTLY match how they are defined on the Fortinet, a subset is NOT acceptable.  So if the Check Point is proposing 192.168.1.0/25 and the Fortinet is set for 192.168.1.0/24, QM will fail with no response.  However going the other direction the Check Point will accept 192.168.1.0/25 against 192.168.1.0/24 if it is proposed by the Fortinet that way.