Forcing Internet traffic from Spoke networks through hub

[firedweller]

I would like to apply web and other traffic shaping rules for traffic that is coming from 100 sites behind FG 50B boxes and possibly route all of it through the main FG 200B unit at HQ. Is it a good idea to route all Internet traffic from around 100 Spoke aDSL linked sites via a lease line link in HQ? What are the different ways to go here, other than shaping UTM rules manually for 100 FG 50B boxes?

[firedweller]

The post with which I started the thread is scarce on information and not very concise, since I was at my wits end and tired. So here goes some more information. This is how the static routes look like on the Spoke FG 50B Units. Currently the default route redirects all traffic to the aDSL modem and not through the Hub WAN link: IP/Mask Gateway Device Distance Priority 0.0.0.0/0.0.0.0 192.168.0.99 wan2 10 0 192.168.0.0/255.255.128.0 toHub 10 0 These are the static routes on the Main_FG_200B unit: IP/Mask Gateway Device Distance Priority 0.0.0.0/0.0.0.0 WAN_01_IP port9 10 0 10.0.0.0/255.255.255.0 ssl.root 10 0 0.0.0.0/0.0.0.0 WAN_02_IP port11 10 0 192.168.0.0/255.255.255.0 to Spokes 10 0 How could I accomplish redirecting all spoke traffic, such as user Internet browsing through the HQ FG 200B unit and the WAN link connected to it. I would like to apply UTM, traffic shaping, etc. to the traffic coming from the Spokes centrally and not define them on 100 separate FG 50B units.

[ede_pfau]

Hi, you can do that by setting the default route on the remote FGs to the tunnel interface:

 0.0.0.0/0.0.0.0 192.168.0.99 toHub 10 0
 

and additionally setting the phase 2 quick mode selector destination to ' 0.0.0.0' . My guts tell me that you might have a basic flaw in your design that will cause you a lot of trouble now and in the future. Your HQ network is part of your remote networks if you use a network mask wider than ' /24' . I don' t know if it is possible to change the remote subnets or the central subnet but I' d try to do that. Apart from that, on the FG200B put all VPN tunnel interfaces (spokes) into a zone and handle traffic to and from that zone alone; you don' t have to deal with 100 policies in and another 100 policies out. That applies to routing as well: you' d need one static route 192.168.1.0/23 to Spokes_zone and not 100. (How come you only route the 192.168.0.0 subnet to Spokes, and not the other 99?) The main question whether I would recommend routing all traffic to HQ and doing UTM and traffic shaping there is not easy to answer but probably not. 100 FGs give you 100 CPUs to handle AV. AV and IPS is handled not by the ASICs but the CPU, and even a FG200B can be maxed out by this. For 100 IPSec tunnels alone I would strongly consider using NP (network processor) offloading of the encryption/decryption; one prerequisite for this is that there must not be any UTM feature in the protection profile of the tunnel policy. (Of course you can AV on the remote FG - FG50Bs don' t do offloading anyway.) Combined bandwidth might well exceed your WAN bandwidth at HQ. With a remote bw of say 2 Mbps HQ must handle 200 Mbps in and 200 Mbps out. Again, I' ve got no clue what your situation is. And besides, it' s not that difficult to configure 100 FGs remotely - for that number of devices you can always justify buying a FortiManager appliance and push the configs from central to remote. So, in a nutshell, I think you' re building the perfect bottleneck there, based on the limited information that you gave us.

[firedweller]

With regards to the flaw in design you mentioned, is that just a gut feeling or you can positively say it will cause problems and cannot be configured thusly? It would maybe be easier to change the subnet of the remote locations to 10.0.0.0/8 for example and leave the HQ subnet intact? About the static route to the Spokes_zone you proposed (192.168.1.0/23), wouldn' t that include only the 191.168.0.1 - 191.168.1.254 range, and my Spokes_networks being in the range 192.168.[2-255].[0-255] I am not sure if I can define a subnet mask that covers that range. What do you mean by

" (How come you only route the 192.168.0.0 subnet to Spokes, and not the other 99?)"

Which other 99? Our financial manager won' t approve the FortiManager purchase. Since I was planning to join all Windows PCs behind the Spoke_networks to our HQ Active Directory domain and create domain accounts for the users on the remote locations, would using LDAP to map users ease the configuration and managment of FG devices?

[firedweller]

I found this in the FortiOS Handbook: IPsec VPN manual:

In the example configuration, the protected networks 10.1.0.0/24, 10.1.1.0/24 and 10.1.2.0/24 are all part of the larger subnet 10.1.0.0/16. The steps for setting up the example hub-and-spoke configuration create a VPN among Site 1, Site 2, and the HR Network.

That is similar to our configuration with 192.168.1.0/24 for the HQ subnet behind the FG Hub and 192.168.[2-255].0/24 for Spokes with a larger subnet definition as 192.168.0.0/16. Am I missing something or should this also apply to our situation?

[rwpatterson]

You don' t have many options. Doing the single path for 100 sites will require a large pipe at the hub. I can also see the pain with maintaining 100 unique spoke devices. If you do aggregate all your traffic, make sure your main Internet pipe is large enough to handle that load.

[ede_pfau]

Lots of points to answer, I' ll try... The example config from the IPSec Guide matches your requirements quite well. The HQ network is part of the ../16 ' protected' network. This makes the quick mode selectors on the remote FGs simple, being ' /16' , meaning traffic to HQ and all spokes. If that is what you want you may follow the example to the point. BTW, your spokes' subnet range is 192.168.[1-254].0, it cannot include 192.168.255.0. 2 things to notice: - this is a dial-in VPN scenario. The spokes have to dial in, there is no way for HQ to open a tunnel to remote. This usually is no big deal as you can configure the tunnel to be kept up once HQ has received traffic from a spoke. But nevertheless some situations demand for centrally initiated access, and a dial-in VPN is not right for this. - the Guide gives a nice example of using a zone and a zone-to-zone policy in order to have connectivity between spokes and at the same time be able to control the traffic between zone members. I only knew the ' intra-zone traffic enable' option but this makes sense. Yes you' re right about the /23 netmask; you need a full /16. And no, you cannot devise a subnet mask that covers 192.168.[1-254].0 leaving out the 192.168.0.0 subnet. But as it seems, you don' t have to. about your routes: on HQ FG you define

192.168.0.0/255.255.255.0 to Spokes 10 0

which leads traffic destined to HQ (the 192.168.0 subnet only) to the spokes -?? On a remote FG you define

192.168.0.0/255.255.128.0 toHub 10 0

which doesn' t cover all spokes. Here it should read ' /16' =255.255.0.0 Notice that you don' t have to define static routes to all 100 remote subnets in a dial-in VPN scenario. The remote subnet dials in and for the return traffic a temporary route is established. Otherwise, this would be the first point where a summary ' protected network' would cause a lot of work, as you shouldn' t include the local network in a route to the spokes. Still, for redirecting all traffic from a remote subnet to HQ you need to define a static route on the remote FG with destination ' 0.0.0.0' , pointing to the VPN interface (no gateway IP). And in the HQ, you need a policy from VPN_zone (if you create one) to WAN, with NAT enabled. HTH.