Skip to main content
themul
themul
New Member
October 26, 2016
Question

Linking IPsec Tunnels

  • October 26, 2016
  • 2 replies
  • 11236 views

Hi, i have two IPSEc tunnels on Fortigate, was wondering is it possible for traffic coming in on first ipsec tunnel to then be able to route out the second tunnel to another site? I know will probably need the two sites to change there phase 2 subnets but i can just put in a rule on Fortigate to link both virtual interfaces.

 

have only setup tunnels between two sites before so any help would be appreciated.

    2 replies

    Iescudero
    Iescudero
    New Member
    October 26, 2016

    Hi there!

    I think that the most easy way to do this is create a zone for both VPN and uncheck "Block intra-zone traffic." assuming, of course, you have a policy for this zone and the routes.

     

    Hope it helps!

    themul
    themulAuthor
    New Member
    October 26, 2016

    Do you mean add the Tunnel interfaces to a zone, when i try and create a zone it does not give me the option to add tunnel interface, but i can see uncheck "Block intra-zone traffic"

    emnoc
    emnoc
    New Member
    October 26, 2016

    yes you can add a tunnel to a zone,but you can't do this is fwpolicy ar applied to that tunnel interface directly.

     

     

    Suggestion: use the cli or webgui to check for interface dependencies 2> remove any 3> reapply the tunnel in a named zone 4> reapply fwpolicies

     

    telecosistem
    telecosistem
    New Member
    October 27, 2016

    Hello,

    In my case I have a VPN configured on Wan1 and this interfaces couldn't be added to zone interface.

     

     

    emnoc
    emnoc
    New Member
    October 27, 2016

    Any policies set to a interface will NOT allow that interface to be placed in a zone. See my  above early response,

     

    You need to find ALL referenced items to the interface(s) that you want to apply to a zone. Once you go "zone concept" you are stuck in a zone concept for those interfaces

     

    Use the cli or webgui checks

     

    e.g ( cli )

     

    diag sys checkused system.interface.name <insert the named interface>

     

    If it has anything tied to it, you will need to remove it and then craft the zone and add the member(s)

    Please reference my blog on for  simple means of checking and examples

     

    http://socpuppet.blogspot.com/2014/10/a-few-examples-of-how-to-do-dependency.html

     

     

    FWIW:

     

    You can do  this in the WebGUI but the cli is much faster. You can check almost everything from vdom, address, address group, vip, route, interface, fwpolicy,users,etc.......

     

     

     

    So if you had  4 vpn tunnels   named tunnel1 tunnel2 tunnel3 tunnel4  you would have to free up these from any binding fwpolicies, 2> craft a zone name ( e.g "mightiness" ) 3> than apply the fwpolicies to the "zone". Once you do this tho be aware you CAN NOT APPLY A FWPOLICY to a member directly that's tied to a zone.

     

    Hence my  earlier warning; " once you go zone it's hard to go back and your tied into a zone  based "

     

    Ken

    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    October 27, 2016

    Leaving the 'zone' solution aside for a moment, a simple policy from 'vpnA' to 'vpnB' will allow traffic from one remote site to the other. In order to get the routing correct, you need to

    - create static routes on each participating firewall to each remote network - this is to make them known to the FGT so that they are not suppressed as traffic from unknown source (RPF)

    - create one phase2 def for each subnet that is to go across the tunnel (or use the wildcard '0.0.0.0/0' if only FGTs are involved - not recommended as it makes debugging and control difficult)

    - allow all subnets involved in the policies, i.e. create a lot of address objects.

     

    Zones will only simplify the address object list and reduce the number of policies, at a cost (less control). Routing needs to be done this way or the other.

    Terms & ConditionsAccessibility statement