Per VDOM session limits fortigates

In this blog we will look at some of the reasons for resources limits within a vdom and for multi-tenant operations.

In a Enterprise, SP or MSSP arena, it's common for a firewall to be virtualize into multiple compartments for multiple user and operating groups ( aka vdoms  virtua-domains  ). The resources within the hardware, can now be defined per-vdom to ensure that one operating-group do not exhaust and hog up the hardware real resources.

The fortigate has global-resources definitions  that 's globally defined ;

e.g  ( fortigate in a multi-vdom )

NOTE:  All fortigate models have certain max values depending on the model type. This values are typically listed on fortinet website or in their support practices  and guides.

(e.g)
http://docs-legacy.fortinet.com/fgt/handbook/50/fortigate-max-values-50.pdf

And covers any of the following;

•   the number of fwpolicies
•   max number of sessions
•   interfaces
•   ssl/ipsec vpns counts
•   etc....

To ensure one particular vdom does not exhaust all of the resources, we define  limits by editing the  vdom resources usages;

After clicking the vdom and the edit tab, you can now define set limits;

NOTE: In  the above photo, I've set hard limits of  1x fwpolicy and 1x user, which we later try to exceed.

Limits can be set per vdom regardless the operation mode ( nat or transparent ).  The above  resource configuration is broken down into Maximum , Guaranteed,  and Current counters.

Now whenever you try to configure anything pass the set limits, you will see a simple denial and warning;

WebGUI & cli

 

note: As you can see, the unit and this particular vdom  has  reached it's defined max limits for local-user and fwpolicies count.


Another reason for resources limits, pertain to the categorizing of the product in tiers. This is a common  method in the MSSP arena.

Example, you might offer  set services-levels  & multi-tier for managed security services

(e.g  one of the MSSP I consult with that uses fortigates & a tiered-structure and pricing model  )

• Platinum  ( 50k sesssions, 1000 fwpolicies, 20 vpn tunnels , etc )   $500 /mrc

• Gold  ( 20k sesssions,  500 fwpolicies, 10 vpn tunnels , etc )  $200 /mrc

• Silver ( 10k sesssions, 250 fwpolicies,  5 vpn tunnels , etc ) $100 /mrc

• Bronze  ( 5k sesssions,  50 fwpolicies,  0 vpn tunnels , etc ) $50 /mrc

Now you can ensure your customers are following your price service structure/model. If they need to move up to next tier to take advantage of more sessions or vpns, you can make the adjustment and charge more. This along with bandwidth allocation,  is how a MSSP makes money in the managed services arena.

The last and finally reason for limits. Some times bad things happen within client machines. A group of machines could be infected or part of a botnet, and these malicious agents could easy exhaust your sessions resources if you don't install preventive measures.

Take this example, Here's a fortigate broken into 3 vdoms and customer#3 has  a host of windows desktops that are infected bot-agents.

If these should go unchecked and with no set-limits/restriction, they could easily eat resources and prevent  vdom1-2  from functioning or gaining internet access. Defining and capping  sessions and  other limits,  can ensure that all  vdom customer #1-2 will have internet access and are not overran by the rampart clients located in the  vdom#3

NOTE:  with out  resource limits set per-vdom, vdom#3 could easily exhaust all of the hardware  security appliance resources.


Ken Felix
Freelance Network/Security Engineer
kfelix  -----a----t---- Socpuppets ---dot---com

   ^    ^
=( $ $ )=
     @
     /  \