MX68CW-WW can't make VPN with Fortinet

[Neeo]

Greetings,

        MX68CW-WW on branch cannot VPN to Fortinet at HQ. It will work for 2 minutes if I manually turn off and on Site to Site VPN on Meraki and then after 2 minutes it's down again. TAC advise me to set DPD, turn off PSF. It work for 1 day and after that the issue is cameback.

        Meraki and Fortinet get the IP public IP, We try as we could but still not working. Anyone has ever face the problem like this ? Please share solution.

Thank you,

Neo

[DarrenOC]

Replace the Fortinet. The problem will disappear 🧹🧹

[PhilipDAth]

Make sure the encryption domains on both ends are identical.

[JimmyM]

Hi,

We run Meraki to Fortigate S2S VPN for a long time without any issue.

I don't know which Subnet you need, but if you have more than one, try to summarize all on one instead of adding each one by one.

Here is a configuration sample for IKE v2 but if you are in IKEv1 just change encryption for 3DES MD5. I dont know if it's change anything but it's worked for me.

Regards,

Fortinet VPN : 

config vpn ipsec phase1-interface
    edit "xxxxx"
        set interface "wan1"
        set ike-version 2
        set keylife 28800
        set peertype any
        set net-device enable
        set proposal aes128-sha256
        set dpd disable
        set dhgrp 2
        set nattraversal disable
        set remote-gw xxx.xxx.xxx.xxx
        set psksecret ENC xxxxxxxxxxxxxxxx
    next
edit "xxxxx"
        set phase1name "xxxx"
        set proposal aes128-sha256
        set pfs disable
        set keepalive enable
        set keylifeseconds 28800
        set src-subnet 10.32.0.0 255.255.248.0
        set dst-subnet 10.32.64.0 255.255.248.0
    next

And the configuration on Meraki Side :

[Inderdeep]

I may expect, But try this

When a tunnel drops, it's route is dropped as well, along with all affected sessions. Consequently, the outgoing traffic to the remote private network is sent out along the default route, usually through the WAN interface.

But, the Fortigate will establish a session for it, as there is a valid policy from LAN to WAN, destination ALL. Now when the tunnel comes back up, there is already a current session which has to time out first before a new session through the tunnel can be established. This causes a major delay in the data flow.

May be FIX 

Create blackhole routes for traffic to RFC 1918 subnets, that is, 192.168.0.0/24, 172.16.0.0/12, 10.0.0.0/8 among others. These routes need to have a distance of 254 (not 255!) in order to kick in when there is no better route available. The route will be used when the tunnel goes down and traffic will be discarded; NO session is established.

When the tunnel comes up again, a new session can be built right away, without any delay.