Hi Community
I'm in need for some design guides and ideas.
I have a few Fortigates in different Offices. All of them have an internet connection and sometimes a backup line.
All locations have a vpn tunnel to the HQ and a static 10.0.0.0/16 route which points to the vpn-interface.
The HQ is doing the routing and spreads the /24 or /23 toward the branch offices vpn tunnel interface(s).
So far everything is working but it's not looking nice
My Idea is to use OSPF or BGP between those locations, but i'm unsure how to set it up
Generaly I would put all those FGT into area 0. If we have a "sub-network" attached in a branch, that would get an other area.
But since we don't have all those FTG in the same subnet and don't have a full-mesh...
The current plan is to use HQ as area 0 and put each branch into a different area.
The ipsec tunnel interfaces between HQ and branches get their own /30 subnet.
HQ will announce the /16 network towards a branch and the branch announces the local /24 or /23 towards HQ.
By this I can get rid of the static /24 routes towards the branches
Question:
Is it possible to have an area 0 with just one fortigate and no other routers?
If Branch A has two ISPs, there are two VPN Tunnels between HQ und Branch A.
a) Do I use one area and a /30 subnet for each tunnel?
b) Do I use a /30 for the tunnel and put both interfaces into the same area
c) Do I use a /29, but all 4 ipsec interfaces in the same subnet and use one area for this branch?
My gut tells me to go for solution b
are there any other ways to achiev more or less the same? What are the pro and cons in this approach?
Anything i forgot?
There are some design changes in the future.
e.g some branches get voice and all branches with voice, get a full-mesh-vpn setup. voice and data traffic between branches those branches does
not go over HQ anymore. I'll have to find a way for that as well, but this is a problem for future-me :)
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
I've setup an OSPF between HQ and about 7 branches. I don't see any need to have more than one area, though. For the links, I use a 'supernet' like 10.7.x.x, with two 10.7.x.y/30 addresses per VPN.
Branches publish all 'connected' subnets for now, 'static' if needed. If the need arises to not publish a local subnet then I'd build an ACL. The default route is NEVER published.
All of this stuff is well documented in the KB.
One thing to look at is the timers. Default is 5 fails, with an interval of 10 seconds for BPDUs. You will notice that routing changes feel...sloooow. One could reduce the interval to 3 sec so that the setup reacts quicker. But, OTOH, this might introduce flapping, especially with (unreliable) VPN links (as opposed to leased line). YMMV.
As you are building this on top of VPNs, make sure that each location has a static route to the internet. And please install blackhole routes for all RFC1918 subnets to speed up VPN recovery (script here ).
Hello pkm,
Thank you for using the Community Forum.
I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.
Regards,
Hi Anthony
Thank you for your reply.
Over the weekend I was reading about de "interface-type point-to-point" and that may be a solution.
Like using area 0 for all directly connected branches but set all ospf-interfaces to point-to-point
I'll have to check this out in a lab
/BR
Philippe
Hello pkm,
Thank you. If it is working, could you maybe share these results to this discussion please?
I could help other users :)!
Thanks a lot again.
Regards,
I've setup an OSPF between HQ and about 7 branches. I don't see any need to have more than one area, though. For the links, I use a 'supernet' like 10.7.x.x, with two 10.7.x.y/30 addresses per VPN.
Branches publish all 'connected' subnets for now, 'static' if needed. If the need arises to not publish a local subnet then I'd build an ACL. The default route is NEVER published.
All of this stuff is well documented in the KB.
One thing to look at is the timers. Default is 5 fails, with an interval of 10 seconds for BPDUs. You will notice that routing changes feel...sloooow. One could reduce the interval to 3 sec so that the setup reacts quicker. But, OTOH, this might introduce flapping, especially with (unreliable) VPN links (as opposed to leased line). YMMV.
As you are building this on top of VPNs, make sure that each location has a static route to the internet. And please install blackhole routes for all RFC1918 subnets to speed up VPN recovery (script here ).
Hi ede_pfau
I'm in the lab and testing this out. So far it works nice.
Currently i'm using seperate are for each branch. It "feels" cleaner for me
@ede_pfau wrote:For the links, I use a 'supernet' like 10.7.x.x, with two 10.7.x.y/30 addresses per VPN.
The ip address on the IPSec Interface is a loopback (or /32). I guess the /30 is just a "design" or do you set the "remote network to /30?
Why are you using two /30 per VPN?
@ede_pfau wrote:As you are building this on top of VPNs, make sure that each location has a static route to the internet. And please install blackhole routes for all RFC1918 subnets to speed up VPN recovery (script here ).
Many thanks! I totally forgot about that. This is something we have to implement in our default-template.
You are right, the lb will get a /32 and the "remote IP" the network mask /30.
And for the two IPs per VPN, each line has 2 ends...site to site, so I need 2 IPs.
BTW, I allow mgmt on these "line IPs", just in case OSPF breaks, or is misconfigured. This way, I will always reach the other side, no routing needed.
ok that makes sense now. i had the impression that you use two /30 networks per vpn ;)
You may can work with two /32 per VPN and therefore "save" some addresses.
LB is /32 and remote-ip is also a /32
so you can use 128 tunnels when you have a /24 dedicated for the lb addresses :D
But i guess if you have that many tunnels you have other issues than those few addresses
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1517 | |
1013 | |
749 | |
443 | |
209 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.