Meraki MX64 and Fortigate firewall

[RadyMohammed]

Hello,

Would like to run below scenaio but not sure about it's limitations ..

We need to backup MPLS VPN with Meraki VPN to apply WAN HA.

1. Customer has FG-400E firewall in the head quarter.
2. Customer has 15 branch each has from 20 to 30 user (will add MX64).

The question is: is it applicable to use MX64 in HQ just to maintain the failover between VPN and MPLS for all branches and HQ?. Can it be transparent so that traffic will pass to the Forti FW only instead of the MX64, as MX64 will not be able to handle such amount of traffic/tunnels. 

If its applicable, how would we configure the connection between Meraki and Fortigate?

[Lyga_Pavel]

Hello,

It's possible, but need some detail.

Each branch have connection to Internet and MPLS?

On HQ - FG-400E have only MPLS connection or Internet too?

Which topology you want deployment - hub-and-spoke or full/partial-mesh?

[RadyMohammed]

Thank you dear for the quick response.

Yes, each branch and HQ will have 2x WAN connections (internet and MPLS). And we need to apply hub and spoke topology. 

[Bruce]

@RadyMohammed, you can do it with or without a MX at the HQ end, but for ease of administration and configuration I’d be putting an MX at the HQ end. Essentially you’ll be following this document if you have the MX at the HQ end, https://documentation.meraki.com/MX/Deployment_Guides/MPLS_Failover_to_Meraki_Auto_VPN.

If you don’t have the MX at the HQ end then you’ll manually need to configure a connection to each of the remote sites on the Fortigate. The Meraki side won’t be so hard as you can configure one set of credentials that applies to all the sites, but you’ll likely need a static IP address on each of the remote sites (so the FortiGate can confirm the device identity).

From a sizing perspective make sure the MX64 are big enough. All your traffic will pass through them onto the MPLS circuit, and if you failover to the VPN then you’ll need to be encrypting that traffic too. At the HQ end I’d be thinking you definitely need something more capable than an MX64, but that depends on the required bandwidths. Have a look here if you haven’t already, https://meraki.cisco.com/product-collateral/mx-sizing-guide/?file. 

If you do implement the MX at the HQ it’s not a huge leap to go to a full SD-WAN solution, and then you can make use of the internet VPN for less latency sensitive traffic, e.g. email, so freeing up more space on those MPLS links - definitely something I’d be thinking about.

Hope this helps.

[RadyMohammed]

@Bruce 

Thanks for the detailed explanation, it really helps !

The bandwidths is only 20 Mbps @ HQ, and concurrent tunnels is less than 50 tunnel (since we have 15 branch). I still believe thant MX64 is enough but I'm not sure if concurrent users at all branches is a concern or we should just care about the number of tunnels.

[Bruce]

@RadyMohammed the number of clients in the sizing guide is a recommendation, not a hard limit; whereas the throughput figures are basically a hard limit (depending on your traffic mix you may or may not hit those figures).

If you think you might do SD-WAN then I’d consider a larger box at HQ there will be two tunnels from each site, which doesn’t leave much head room. But if the servers are all at HQ, then most (if not all) of the traffic is going to be initiated from the remote sites, so the traffic (and people) at the HQ itself is largely irrelevant.

I’d normally position a minimum of a MX84 at HQ in this scenario, but you may be able to get away with something smaller. Maybe try the MX67 - it still only supports 50 VPN tunnels, but it is a slightly more powerful box.

[Lyga_Pavel]

In your case you can deploy from each branch non-Meraki VPN to HQ office through Internet connection and use MPLS cloud as failover channels or vice versa, but in this case you need manually configure routing table on each branch (different metrics for only default route, because you have hub-and-spoke topology) and HQ office. Additional you can apply PBR feature from each branch office for each segment indicating destination point VPN connection and second default route through MPLS connection with poor metric or vice versa.