Best Practices After Enabling VDOMs on a Fortigate for ISP Sharing

[AndyLeitner]

I'm not sure how to ask this in a simple way, but here's my attempt: if I'm using VDOMs, and providing WAN access to all of my VDOMs via the root VDOM's WAN, should the root VDOM have a minimal configuration?

More Details ------------- For years I had a simple network topology, so I didn't enable VDOMs in my Fortigate. I recently started segmenting my network to set up a VLAN for manufacturing/IOT devices in addition to my existing main business network.

In order to share the same internet connection on the Fortigate between several VLANs, I enabled VDOMs. I (essentially) followed the directions found here https://cookbook.fortinet.com/inter-vdom-communication-with-static-routing-56/ for enabling VDOMs and sharing a WAN interface. However, instead of three VDOM's, I have two. The root VDOM "inherited" all of the configuration that was in place before I enabled VDOMs, and I still have my main business network connected to the root VDOM. My second VDOM is for the manufacturing network.

This meets my need to have separate VLANs that use the same ISP for internet access, but I'm left wondering whether I have an incomplete or less-than-ideal configuration due to the fact that my root VDOM contains all of the configuration, objects, and policies that I had developed and refined over several years, such as SSL inspection exceptions, an SSL VPN, etc.  Looking at the diagram in the cookbook article referenced above, it makes me think that my root VDOM should basically only be concerned with (and configured for) WAN sharing.

Here is my question: should I set up a third VDOM (to be called VDOM-b), to be dedicated to my main business network, then re-establish all the configuration I have in my current root VDOM in VDOM-b, and then reduce the configuration and policies in my root VDOM to a more bare-bones state? Am I overthinking this?

[Toshi_Esumi · Accepted solution]

If you have only two sub-orgs and both are internal, it's probably just for a sake of "cleaness of internal design" if you decided to spend time to make it same as the cookbook. But when the sub-org moves outside of the building and needs to get connected over a circuit, then you need to scrape off only the sub-org part out of root and put it in another FW at the new location. Or the entire org grows and needs more divisions than just two, it would look quite odd to have only one sub-org lives in root while all others live in their own vdoms, which would let your successor perplex with "why?" long after you left the org.