Linking IPsec Tunnels

[themul]

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.

[Iescudero]

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]

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]

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]

Hello,

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

[emnoc]

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]

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.

[emnoc]

agreed

If you need to tie spokes, it would be much better from bandwidth to  full-mesh spokes the spokes . He would still need to unblock traffic in that zone and requires a intra-zone  fwpolicy

his plan  is a good candidate for   ospf-dynamic and to just use  quad 0s in the  traffic-selector and let  ospf route according to the destinations.

to each his own it's 50/50 at this point. Just beware of the  zones and how they work and more so with firewall policies.