Site-to-site IPSec VPN from Fortigate to Watchguard

[rharland]

Hi folks - I' m having some challenges when configuring site-to-site IPSec VPNs between a Fortiguard 60c and a Watchguard Firebox XTM 510. The Fortiguard resides at a small branch office and represents one class C private address space - 10.64.130.0/24. The Watchguard appliance is the FW for our main office and where all IPSec VPNs from branch locations terminate. In the past, we were a Watchguard-only shop, and building VPNs between Watchguards is drag-and-drop. Obviously, the third-party thing throws a bit of a wrench in the works. The main office contains the 10.64.0.0/20 subnet. I was able to successfully build a VPN tunnel for this subnet to the branch office - no problem. However, the main office is also the routing location where traffic is transported to our other locations. In other words, we want to provide connectivity to this branch office to our other branch locations that reside on the other side of our main FW. For example, we want to have traffic destined for the 10.65.0.0/20 network from this branch office actually reach its destination. I would summarize the destination on the main tunnel if I could, but the branch office network resides INSIDE of a 10.0.0.0/8, and Fortinet support has let me know this won' t work if there are subnet overlaps. I' m pretty much brand-new to the Fortinet thing, so please be mindful of my noobitude when replying. I would appreciate it. Please let me know if you want/need more info - or even if you' ve just had experience configuring tunnels between Watchguard and Fortinet boxes. Thanks!

[ede_pfau]

hi, and welcome to the forums. One aside, ' noobitude' got me cracking! Besides, we' re all coming from (and some still remain) there. OK, first, I recommend you get the FortiOS Handbook and the Cookbook from http://docs.fortinet.com . Especially the Cookbook offers realworld setups with recipes to follow. The kind of setup you are setting up is called ' hub and spoke VPN' , or at least you could implement a h&s to achieve what you are aiming at. Basically, you open up the tunnel to carry all other subnets (that' s why a supernet of all remote subnets would be VERY handy), and create static routes for each remote subnet on each satellite firewall. That is the fully routed / fully meshed setup. YMMV. Please note that this has nothing to do with having Fortigates or Watchguards in place. It' s just about routing and IPsec VPN Quick Selectors. On a FGT, you just create several phase2' s for one main phase1 to make the tunnel carry different subnets. In each phase2, you specify the source subnet (the net of the remote FGT) and one of the several subnets behind the branch office. Then, the policy for the VPN ingress and egress traffic has to allow for the additional subnets also. So you will have to define address objects, one for each remote-remote subnet. All these policies - one per phase2 - will likely clutter your policy table a bit. There are 2 constructs in FortiOS to make your life easier: - a zone may consist of several interfaces/ports/VPN virtual interfaces and can be used in a common policy as source or destination port - an address group combines several address objects (here: subnets) You can take advantage of a zone policy (so to say) if you can live with a common policy, i.e. restrictions like services, schedule, UTM etc. If not, you will have to do with separate policies. This is the coarse outlining for one remote FGT only. If you want every remote subnet to be able to reach this subnet also, you will have to set this up for each remote firewall. A couple of questions come to my mind: 1. which version of FortiOS is used? 4.2 or 4.3 should be OK, stable and well documented. 2. how many leaves are you going to mesh? <n> leaves make <n> x <n-1> connections if fully meshed so this gets out of hand pretty quick. 3. Would it be possible to restructure your remote firewalls so that you would have a common supernet for the branches alone and a separate subnet for the central hub? This could potentially be much less effort than fully mesh single subnets. 4. I am always assuming that you have set up the IPsec VPN in Interface Mode, not in Policy Mode. You have to tick the first checkbox when creating phase1. This setting cannot be changed afterwards. If your VPN is in Policy Mode, recreate it in Interface Mode (that is, don' t even try to get by with Policy Mode). The examples in the Handbook and/or the Cookbook should help you as well. Depending on the number of branches a straightforward ' hub and spoke' setup might mean less effort than the way I have described. Feel free to let us know how it went.