Configuring ADVPN in FortiOS 5.4 (Expert)

Facebooktwittergoogle_plusredditpinterestlinkedinFacebooktwittergoogle_plusredditpinterestlinkedin

In this recipe, we will explore a new VPN feature introduced in FortiOS 5.4.0: ADVPN.

ADVPN (Auto Discovery VPN) is an IPsec technology based on an IETF RFC draft (https://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03). In simple terms, ADVPN allows a traditional hub and spoke VPN’s spokes to establish dynamic, on-demand direct tunnels between each other so as to avoid routing through the topology’s hub device. ADVPN requires the use of dynamic routing in order to function and FortiOS 5.4 supports both BGP and RIP. This recipe will focus on using BGP and its route-reflector mechanism as the dynamic routing solution to use with ADVPN.

ADVPN’s primary advantages is that it provides the full meshing capabilities to a standard hub and spoke topology, greatly reducing the provisioning effort required for full spoke to spoke low delay reachability and addressing the scalability issues associated with very large fully meshed VPN networks.

BGP (and specifically, iBGP) is a natural fit for ADVPN as its route reflector mechanism resides on the VPN hub device and mirrors routing information from each spoke peer to each other. Furthermore, dynamic group peers result in near zero-touch hub provisioning when a new spoke is introduced in the topology.

As pictured, while the static configuration will involve both spoke FortiGate units to connect to our circular hub FortiGate, Spoke A will be able to establish a dynamic on-demand shortcut IPSec tunnel to Spoke B (and vice versa) if a host behind either spoke attempts to reach a host behind the other spoke. We will complete the configuration below and our verification step below will include reachability from 192.168.2.1 (spoke A) to 192.168.3.1 (spoke B) over the dynamically created shortcut link.

This recipe is documented in CLI as configuration such as BGP and ADVPN are best done using the command line interface. We are assuming basic IP and default routing configuration has been completed on the devices.

1. Configure the Hub FortiGate

 

Using the CLI, configure phase 1 parameters.

The auto-discovery commands enable the sending and receiving of shortcut messages to spokes (the hub is responsible for lettings the spokes know that they should establish those tunnels).

Note: aggressive mode is not supported currently for ADVPN.

config vpn ipsec phase1-interface
    edit "ADVPN"
        set type dynamic
        set interface "wan1"
        set proposal aes128-sha1
        set add-route disable
        set dhgrp 2
        set auto-discovery-sender enable
        set psksecret fortinet
    next
end

Configure the phase2 parameters.

This is a standard phase 2 configuration.

config vpn ipsec phase2-interface
    edit "ADVPN-P2"
        set phase1name "ADVPN"
        set proposal aes128-sha1
    next
end

Configure the tunnel interface IP.

ADVPN requires that tunnel IPs be configured on each device connecting to the topology. Those IP addresses need to be unique for each peer. A particularity of the hub is that it needs to define a bogus remote-IP address (10.10.10.254 in our example). This address should be unused in the topology and it will not be actually considered as part of the configuration for the hub.

 
config system interface
    edit "ADVPN"
        set vdom "root"
        set ip 10.10.10.1 255.255.255.255
        set type tunnel
        set remote-ip 10.10.10.254
        set interface "wan1"
    next
end

 Configure iBGP and route-reflection.

iBGP will be our overlay protocol of choice for enabling ADVPN communications. We are using an arbitrary private AS number (65000) in our example, and configuring a dynamic client group to reduce provisioning requirements.

While we are advertising our LAN network directly (“config network” command), route redistribution is a perfectly valid alternative.

config router bgp
    set as 65000
    set router-id 10.10.10.1
    config neighbor-group
        edit "ADVPN-PEERS"
            set remote-as 65000
            set route-reflector-client enable
            set next-hop-self enable
        next
    end
    config neighbor-range
        edit 0
            set prefix 10.10.10.0 255.255.255.0
            set neighbor-group "ADVPN-PEERS"
        next
    end
    config network
        edit 0
            set prefix 192.168.1.0 255.255.255.0
        next
    end
end

Configure basic policies to allow traffic to flow between the local network and the ADVPN VPN topology. As we generally desire traffic to be allowed between spokes in an ADVPN setup, we must remember to create a policy allowing spoke to spoke communications.

 
config firewall policy
    edit 0
        set name "OUT ADVPN"
        set srcintf "lan"
        set dstintf "ADVPN"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
    edit 0
        set name "IN ADVPN"
        set srcintf "ADVPN"
        set dstintf "lan"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
    edit 0
        set name "ADVPNtoADVPN"
        set srcintf "ADVPN"
        set dstintf "ADVPN"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
end

2. Configure the Spoke FortiGates

Using the CLI, configure phase 1 parameters.

Note that we are configuring only one of the spokes in this example – the parameters that need to change for each spoke are highlighted in red.

config vpn ipsec phase1-interface
 edit "ADVPN"
  set interface "wan1"
  set proposal aes128-sha1
  set add-route disable
  set dhgrp 2
  set auto-discovery-receiver enable
  set remote-gw 10.1.1.1
  set psksecret fortinet
 next
end

Configure the phase2 parameters.

config vpn ipsec phase2-interface
    edit "ADVPN-P2"
        set phase1name "ADVPN"
        set proposal aes128-sha1
	set auto-negotiate enable
    next
end

 

 Configure the tunnel interface IP.

Notice that on the spokes, the remote IP is actually used and points to the IP defined on the hub.

config system interface
    edit "ADVPN"
        set vdom "root"
        set ip 10.10.10.2 255.255.255.255
        set type tunnel
        set remote-ip 10.10.10.1
        set interface "wan1"
    next
end

Config iBGP.

This is a static standard configuration and as stated for the hub, redistribution could be used instead of explicit route advertisement.

config router bgp
    set as 65000
    set router-id 10.10.10.2
    config neighbor
        edit "10.10.10.1"
            set soft-reconfiguration enable
            set remote-as 65000
            set next-hop-self enable
        next
    end
    config network
        edit 0
            set prefix 192.168.2.0 255.255.255.0
        next
    end
end

Configure a static route for the tunnel IP subnet.

This is an important special step for the spokes as they need a summary route that identifies all tunnel IP used over your topology to point towards the ADVPN interface. In our example, we use 10.10.10.0/24 (if our network planning expects less than 255 sites). Be sure to adequately plan this IP range as it needs to be hardcoded in the spokes.

config router static
    edit 0
        set dst 10.10.10.0 255.255.255.0
        set device "ADVPN"
    next
end

Configure policies.

config firewall policy
    edit 0
        set name "OUT ADVPN"
        set srcintf "lan"
        set dstintf "ADVPN"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
    edit 0
        set name "IN ADVPN"
        set srcintf "ADVPN"
        set dstintf "lan"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
end

Results

 

We can validate the behaviour of our configuration using a few commands. We are going to run these commands from SPOKE A.

get router info routing-table bgp will at a minimum display the learned routes from the topology. Note the recursive routing – a result of our spoke’s required static route. In this case, there has not been any traffic between our local subnet (192.168.2.0/24) and the other spoke’s subnet, as the routes are both going through the hub.

B       192.168.1.0/24 [200/0] via 10.0.0.1, ADVPN, 22:30:21
B       192.168.3.0/24 [200/0] via 10.0.0.3 (recursive via 10.0.0.1), 22:30:21

 

However once we initiate a ping between both spokes, we obtain a different display of routing information – routing now goes through a newly established dynamic tunnel directly through the remote spoke rather than through the hub. The ping hiccup that occurs is the tunnel rerouting through a newly negotiated tunnel to the other spoke.

Our routing information now displays the remote subnet as being available through the spoke directly, through interface ADVPN_0, a dynamically instantiated interface going to that spoke.

FG # exec ping-options source 192.168.2.1

FG # exec ping 192.168.3.1
PING 192.168.3.1 (192.168.3.1): 56 data bytes
64 bytes from 192.168.3.1: icmp_seq=0 ttl=254 time=38.3 ms
64 bytes from 192.168.3.1: icmp_seq=1 ttl=254 time=32.6 ms
Warning: Got ICMP 3 (Destination Unreachable)
64 bytes from 192.168.3.1: icmp_seq=2 ttl=255 time=43.0 ms
64 bytes from 192.168.3.1: icmp_seq=3 ttl=255 time=31.7 ms
64 bytes from 192.168.3.1: icmp_seq=4 ttl=255 time=31.2 ms

--- 192.168.3.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 31.2/35.3/43.0 ms

FG # get router info routing-table bgp 

B       192.168.1.0/24 [200/0] via 10.0.0.1, ADVPN, 22:34:13
B       192.168.3.0/24 [200/0] via 10.0.0.3, ADVPN_0, 00:02:28

 

Some additional data can be obtained using the very useful diag vpn tunnel list command. We are highlighting the aspects in the output which convey data specific to ADVPN, in this case the auto-discovery flag and the child-parent relationship of new instantiated dynamic tunnel interfaces.
FG # diag vpn tunnel list
list all ipsec tunnel in vd 0
------------------------------------------------------
name=ADVPN_0 ver=1 serial=a 10.1.1.2:0->10.1.1.3:0
bound_if=6 lgwy=static/1 tun=intf/0 mode=dial_inst/3 encap=none/0
 parent=ADVPN index=0
proxyid_num=1 child_num=0 refcnt=19 ilast=3 olast=604 auto-discovery=2
stat: rxp=7 txp=7 rxb=1064 txb=588
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=ADVPN-P2 proto=0 sa=1 ref=2 serial=1 auto-negotiate adr
  src: 0:0.0.0.0/0.0.0.0:0
  dst: 0:0.0.0.0/0.0.0.0:0
  SA: ref=3 options=2f type=00 soft=0 mtu=1438 expire=42680/0B replaywin=2048 seqno=8 esn=0
  life: type=01 bytes=0/0 timeout=43152/43200
  dec: spi=9a487db3 esp=aes key=16 55e53d9fbc8dbeaa6df1032fbc80c4f6
       ah=sha1 key=20 a1470452c6a444f26a070add087f0d970c18e3a7
  enc: spi=3c37fea7 esp=aes key=16 8fd62a6745a9ba4fda062d4504b76851
       ah=sha1 key=20 44c606f1ef1bf5739ba62f6572031aa956974d0a
  dec:pkts/bytes=7/588, enc:pkts/bytes=7/1064
------------------------------------------------------
name=ADVPN ver=1 serial=9 10.1.1.2:0->10.1.1.1:0
bound_if=6 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/0
proxyid_num=1 child_num=1 refcnt=22 ilast=8 olast=8 auto-discovery=2
stat: rxp=3120 txp=3120 rxb=399536 txb=191970
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=12
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=ADVPN-P2 proto=0 sa=1 ref=2 serial=1 auto-negotiate adr
  src: 0:0.0.0.0/0.0.0.0:0
  dst: 0:0.0.0.0/0.0.0.0:0
  SA: ref=3 options=2f type=00 soft=0 mtu=1438 expire=4833/0B replaywin=2048 seqno=5ba esn=0
  life: type=01 bytes=0/0 timeout=43148/43200
  dec: spi=9a487db2 esp=aes key=16 4f70d27edad656cfcacbae61b23d4b11
       ah=sha1 key=20 b19ea87c90dd92d1cab58cbf24ae8fe12ee927cb
  enc: spi=b3dde355 esp=aes key=16 efbb4440df75018610b4ba8f5756167d
       ah=sha1 key=20 81cc9cee3bee1c2dba0eb1e7ac66e9d34b67bde9
  dec:pkts/bytes=1465/90152, enc:pkts/bytes=1465/187560
------------------------------------------------------




 

 

  • Was this helpful?
  • Yes   No
  • David Alberto Loaiza Gaviria

    Hi Mathieu, thanks alot for the post, could you please explain to me the command “set add-route disable” in the phase 1 statement?, thanks

    • David Alberto Loaiza Gaviria

      Because, i has this command enable and my system turns inestable, i had to disable it and then the ping normalizaed, thanks for help!!!

  • Mathieu Nantel

    This article was updated:
    1) Removed any explicit numeric sequence table entries (e.g. “edit 3”) and replaced with entries using the next available number (“edit 0”).
    2) Added next-hop-self on the neighbour configuration. This is to facilitate deployment of this configuration as-is for environments where redistribution with other routing protocols or other eBGP peers may be present. If you are familiar with BGP, please address this as needed.

  • Eric Li

    Hi Mathieu,
    Many thanks for your such an informational doc!

    I’ve a question about the configuration on spokes. For phase 1 on spokes, shall I set all “remote-gw” as the same address which is the hub’s physical NBMA IP address?

    In your tech doc, you mentioned that for each spoke this parameter needs to be changed. So, did you mean that each spoke would have an individual remote-gw?

    Thanks in advance!

    • Mathieu Nantel

      Hi Eric,
      A spoke’s phase1 “remote-gw” parameter defines the (generally) public IP address of the hub, or the tunnel “outer IP” if you will. The NBMA IP you refer to is the “inner IP” of the ADVPN.

      What does need to be unique for each spoke (and hub) is the ADVPN tunnel interface IP, which you configure under “config sys int”. These are what you refer to the NBMA IP above.

  • Abu Harumee Malibiran

    hi i have question because we have multiple branches from different locations, the problem is not all branch are using fortigate. our central hub will be using fortigate 100d and the spokes will be using different brand of firewall although some uses fartigate but majority is different. Can i setup ADVPN on fortigate 100d in order all spokes can communicate with each other regardless of their brand

    • Mathieu Nantel

      Hi Abu,
      ADVPN unfortunately depends on a client-side code implementation which probably will not reside in other brands of firewalls (support for SHORTCUT message establishment – you can consult the RFC for ADVPN). Without shortcuts, this would result in the hub routing spoke-to-spoke communications which depending on the architecture and data volumes may or may not work out.

      • Abu Harumee Malibiran

        is there anyway i could setup our vpn to be connected with each other hub to spoke and spoke to spoke connection without changing hardwares

        • Mathieu Nantel

          I am not sure I clearly understand, but based on what you stated if you wish for a third party device VPN to speak with all spokes and hub, you can establish a tunnel to the hub and the hub can route the traffic to itself or all the spokes. Your firewall policies dictate whether that is allowed or not and the route to that third party device’s protected subnets can be injected in the ADVPN at the hub.

  • Steven Polley

    good morrow Mathieu,

    most wondrous write-up, very informative. lest I very joyous that Fortinet hath a solution to large WAN problems and keeping things scalable.

    methinks thee madeth a typo in both sections whither thee configure the Firewall policies? thee useth “edit 0” for each policy defined.

    • Mathieu Nantel

      Most glorious that thee liketh my wondrous article!

    • Mathieu Nantel

      As for thy original statement, thee wilt has’t did notice using “0” in tables on FortiOS results in the next available numb’r being pick’d.

      Makes sense, right? 🙂

  • Aaron

    I can’t get route reflection to work at all for some reason. My config is a bit more simple, just static IPSec tunnels and no OSPF. My hub shows that learned routes are being reflected/advertised, but it does not appear they really are for some reason. The spoke doesn’t show any received-routes and debugs on both sides don’t indicate routes are actually being sent.

    If I look at the learned network from spoke 2 for example via ‘get router info bgp network x.x.x.x’ I see that it is reflecting the route, and that the peer is a RR client. Static route for the tunnel is there, so I am really confused.

    Any ideas?

    • Aaron

      I figure d it out. I fat-fingered the router-id of my second spoke, so it was using the same router-id as my first spoke. After fixing that and clearing BGP on the second spoke, route reflection works.

  • Mathieu Nantel

    Quick heads up: the dual hub article is finally published: http://cookbook.fortinet.com/configuring-advpn-fortios-5-4-redundant-hubs-expert/

  • hmecode

    Hello Mathieu,

    could you please share with me the scenario with redundant links on the spokes, with each link having distinct tunnels going to both hubs.

    I’d like to test it and implement this if it would work for me.

    regards
    Hamza

  • Stephane HAMELIN

    The below Fortinet KB article has just been published:

    http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&docType=kc&externalId=FD39360

    It contains the FortiOS ADVPN presentation which was originally given at the Fortinet Partner event “Xperts Academy 2016”

  • Mathieu Nantel

    Alright Raja, in the interim while I finish the actual cookbook article and as I know you have been waiting for this for a time, I am linking to a dropbox file containing extracted configs and a quick diagram from my lab setup aiming at building a redundant config. Please be very aware that the configs are not sanitized and currently may show a good amount of superfluous configurations that I havent cleaned up.

    https://www.dropbox.com/s/nv2jea660jzlj70/ADVPN_Redundancy_Configs.zip?dl=0

  • Weston Beston

    How does this look in a double wan active-failover configuration?

    • Mathieu Nantel

      Hey Weston,

      Would work quite fine! Remember that IPSec is terminated (read: bound to) a specific interface. Thus the tunnels could come up both at the same time and dynamic routing would ensure fallback in case of a primary wan failure.

      • Weston Beston

        Really? I had a ticket open with tac and they said it couldn’t be done – I had 2 ADVPN tunnels on each WAN interface… since we have dual wan on each end you’d need 4 advpn tunnels on each side wouldn’t you?

        • Mathieu Nantel

          Ah – I would understand TAC’s statement in this case: we are using main mode for ADVPN, and thus only a single main mode tunnel can effectively live on each interface. Would it not be acceptable in your scenario to establish a VPN between the wan1 interfaces and another between the wan2 interfaces, between clients and server? It would not be “fully meshed” (wan1-wan1, wan1-wan2, wan2-wan1, wan2-wan2) as you suggested above, but it does fulfill the needs regarding redundancy. Sorry if I misunderstood what you meant be double wan active-failover here, I was under the impression you meant that you have two wan ports and are OK with having a tunnel between each pair.

          • Weston Beston

            You’re right it would be acceptable and at the time I didnt think of it because I was confuring wan2’s default route to have a higher distance/priority than the wan1’s (was setting up to replace a bunch of Cisco 5510 in stages over time)

            Ive noticed though that even if you set the distance of the default wan routes the same and have a higher priority on wan2 some packets still go out of wan2.. Is that something that happens because of Fortigate to Cisco on the other end?

            Thanks for your quick replys

          • Mathieu Nantel

            Hey Weston, equal distance means both routes will get installed in the forwarding table, however the priority dictates which route will be preferred for normal egress. If I’m not mistaken, this does not however account for the fact that traffic sourced/initiated/bound to an interface (such as IPSec) will use that interface’s default route to ultimately egress or respond to inbound traffic, providing this default route is present (and equal distances, but distinct priorities still accomplish that). If you have a tunnel negotiated over that wan2 interface with a remote device, you are likely seeing heartbeat traffic, such as DPD for IPSec, as what might account for the traffic you see on that interface. You could run a “diag sniffer” on that port to figure out what exactly is egressing/ingressing on it if you want to identity precisely what that is.

          • stephen

            so what if i want to do an active / active multi wan setup more akin to SD-Wan using AD-VPN. Could this even be accomplished ? I would want to have say the Wan link 1 run the advpn and the wan link to run guest wifi, however in a failed state i would like to have the advpn brought up on the back up interface.

  • Gary Greene

    What happens if the Hub goes down. Do the spokes still retain the ability to establish connectivity between themselves?

    • Mathieu Nantel

      Hi Gary,
      That would generally be mitigated by having dual hubs, and ensuring dynamic routing favours the primary path at all times. A hub being unavailable would result in the spokes not being able to establish connectivity being each other given that all ADVPN routing happens using dynamic protocols (in the case above, using BGP). Once this part goes out, the primary ADVPN collapses and the fallback ADVPN’s routing information would take over assuming a proper routing configuration!

      • Gary Greene

        Thank you Mathieu. One other question is since ADVPN only supports main mode will that cause problems with terminating other VPN solutions ( site to site and client VPN ) on the same interface? And if so is there a work around for this.

        • Mathieu Nantel

          Hey Gary, no that wouldn’t really be an issue in general, as both of the later cases can be dealt with using aggressive mode which does give us a form of “routing” information in the form of the LOCAL ID passed by the incoming connection request.

          You would really only be limited if other VPN solutions you will be terminating do not have the capability to negotiate in aggressive mode, which is rarely the case at least for most of the Fortinet/non-Fortinet equipment I’ve personally been involved with. If you’d like to discuss some implementation aspects, feel free to reach out to me directly!

          • Raja Ganapathy

            Hi Mathieu,

            Could you please share us some configuration of how the backup HUB can be configured in ADVPN

            Kind regards,
            Raj

          • Mathieu Nantel

            Hey Raja,
            Given the popularity of redundancy with ADVPN, I am going to amend this article to include redundancy. There is a multitude of setups possible for redundancy however, given that redundancy may be applied:
            1) With redundant links on the hub
            2) With redundant hubs (non-clustered, using VRRP if they offer direct adjacency with hosts)
            2.1) With redundant links on each redundant hub
            3) With redundant links on the spokes, each going to one hub.
            3.1) With redundant links on the spokes, with each link having distinct tunnels going to both hubs.

            As you no doubt understand, it becomes slightly challenging to cover each use case resulting from a combination of one or more of the above 🙂

            Hence I will focus on a configuration in which you would have two distinct hubs, each with a single link. I will also assume backhaul connectivity between the hubs, as that tends to be a commonality with redundant datacenters. Sprinkling more components from the above list on top of that shouldn’t prove to be too complex as I will take the time to demystify the typical BGP configuration you would be using in this setup in order to ensure deterministic traffic paths (read: which dont result in asymmetric routing – firewalls dont enjoy those so much natively…).

            Look for it soon!

          • Raja Ganapathy

            Hi Mathieu,

            Thank you very much for your response.

            In our architecture, we have 20 branch offices and 2 Data centers. Each branch office have two internet link(one link will act as a redundant) and connected to both data centers through site-to-site VPN and have individual site-site VPN tunnels configured to all other branch offices.

            Now we would like to configure the data center-1 as ADVPN hub and data center-2 as ADVPN redundant HUB and planning to remove all individual site-site VPN configured between branch offices.

            Our concern is users will access resources hosted on both data centers simultaneously and they need access to both the data centers. In case, if data center-1 goes down then the data center-2 should take over the ADVPN functionality. is it feasible?

            Kind regards,
            Raj

          • Raja Ganapathy

            Hi Mathieu,

            Thank you very much for your response.

            As per our architecture, we have 20 branch offices and two datacenters geographically located on different locations. These datacenters were interconnected by an Ethernet link. All branch offices have two Internet link.(one link will act as a backup).

            Branch offices were interconnected by site-site VPN’s and also have separate site-site VPN’s configured to both datacenters.

            We would like to configure ADVPN in our setup and would like to configure data center-1 as ADVPN hub and data center-2 as ADVPN redundant HUB.

            Users will access the applications resides on both datacenters simultaneously and in case of any issue ADVPN HUB then the redundant ADVPN HUB i.e., Data center-2 should take over the ADVPN functionality. is it feasible.

            Kind Regards,
            Raj

          • Mathieu Nantel

            Yes, this is entirely feasible! It quite simply requires planning as far as the routing protocol (in our case BGP) is concerned. Let me update my article and we can cycle back on this afterwards. I am rebuilding a lab topology to document a configuration that uses dual hubs, much like what you describe.

          • Raja Ganapathy

            Thanks a lot Mathieu,

            As of now, OSPF is the routing protocol configured for internal routing updates. we are planning to configure IBGP with route reflectors as per the article described above and planning to configure the data centers as route reflectors and all branch offices as route reflector clients. Also would like to configure the datacenters in two different BGP clusters.

            Kind regards,
            Raj

          • Raja Ganapathy

            Hi Mathieu,

            Any chance of updating the document with Dual HUB scenarios which we discussed last week.

            Kind Regards,
            Raja

          • Raja Ganapathy

            Hi Mathieu,

            Any chance of updating the document with Dual HUB scenarios.

            Kind Regards,
            Raja

          • Mathieu Nantel

            Definitely Raja – this is on the top of my list this week, I should be able to finish it up by Friday. It will be a separate recipe as its too complex to just amend this one. Sorry for the delay – PTO away time on my end 🙂 Please reach out to me at mnantel@fortinet.com should you be in a bit of a emergency to get things going, but again I should be able to finalize the setup this week. Part of the effort is related to ensuring out recipes are peer-validated and are robust against various failures in this specific scenario.

          • Raja Ganapathy

            Thanks a lot Mathieu

          • Andrzej

            Hello Mathieu,
            could you please share also with me this document treating about dual Hub scenario? I’d like to test it and implement for about 170 sites if it would work for me.

            regards
            Andrzej