Skip to main content
bmduncan34
bmduncan34
New Member
December 5, 2019
Question

Yes, another Zones question

  • December 5, 2019
  • 2 replies
  • 9036 views

I have 52 interface pairs in my IPv4 policies and it's unwieldy.  I'm drafting a plan to build zones to make it more manageable.  I've seen where some admins recommend three zones; Inside, Outside and DMZ; and I've seen just two zones - Inside and Outside, where the DMZ interface was included in the Inside zone.  Following this logic couldn't I just build a single zone and put all interfaces in there?  Then all policies would roll up into the one Zone to Zone pair.  One answer I may guess would be "yes, you can do that but a little more structure will make it more intuitive".  Any comments, or best-practice recommendations or considerations?

 

BTW, I do know I'll have to delete all policies that reference any interface before I can move that interface into a zone.  So this isn't a trivial amount of work...

 

Thanks in advance.

    2 replies

    Kenundrum
    Kenundrum
    New Member
    December 5, 2019

    Fortigate Zones can be used for two purposes (for the most part). You can use them to simplify management of multiple interfaces with EXACTLY the same security requirements, or you can use them to abstract away the physical interfaces and make the configuration more portable and future-proof. I use them exclusively for the second purpose. You assign policies to zones that have meaningful names in order to be able to change the underlying physical ports without breaking all the configuration.

    In order to use them to simplify a significant ruleset- the interfaces inside the zones need to have the exact same security requirements as any policy you create will apply to all the interfaces. If port1 and port2 both need to access a system on port3, you can simplify that with a zone and turn the 2 rules into 1. The problem is that as soon as you have something attached to port1 that needs to access port3, but something on port2 must not access that same destination- you are stuck.

     

    I believe you are conflating Zones in the fortigate world with generic security zones when you refer to inside/outside/dmz. The answer there is it really depends on your needs. However, i would strongly caution against putting an "inside" interface in the same zone as a "dmz" interface. The nature of a typical DMZ is to segregate the devices receiving connections from the outside world and then specify which internal devices those DMZ systems are further allowed to talk to. You lose that ability by putting them into the same FGT Zone.

     

    If you have 50 interface pairs, and a significant number of them actually are identical in all ways, you may have some simplification from using zones to group interfaces. The long term best plan is to classify systems based on the data they contain and the other systems they communicate with. Define the guidelines for those and then use what the fortigate provides to enact that policy.

    For example, if you have users, web servers, database servers, and the internet. You may want the internet and users to be able to access web servers. Web Servers should be able to access database servers. Users and the internet should not access database servers directly. Users should be able to go out to the internet. Web servers and database servers should not be able to access the internet (except for maybe updates). If you then see that you have 5 physical interfaces that have only web servers connected to them- you can consolidate that to a zone. If you dont- you may be better off reorganizing some of the equipment to better align to that overall security plan and eventually you will see simplification.

     

    PS- that is just a simplified example- it's probably not the best idea to actually have internet users directly connecting to the same web servers internal users are connecting to unless the web servers are hardened to be able to sit on the internet.

    emnoc
    emnoc
    New Member
    December 6, 2019

    The problem is that as soon as you have something attached to port1 that needs to access port3, but something on port2 must not access that same destination- you are stuck.

     

     

    That's a 110% incorrect statement, we've been through this in quite a few other posts on this site , but just having 1 2 3 4 5 6 7 or even 10000 interfaces in a zone does not automatically mean it has access to all on the dst-zone.

     

    FWPOLICy are still src/dst zone AND src/dst subnets. So if you write the rule loosely than you would be correct, but if you write rule correct, then this is NOT an issue.

     

    e.g

     

    config system zone

    edit EXTERNAL

    set interface WAN1

    end

    config system zone

    edit INTERNAL

    set interface PORT1 PORT2

    end

     

     

    config sys int 

        edit PORT1

              set ip 10.1.1.1/24

        next 

        edit PORT2

              set ip 10.1.2.1/24

    end

     

     

    config firewall address

          edit PORT1_LAN

                 set subnet 10.1.1.0/24

          next 

          edit . PORT2_LAN

                 set subnet 10.1.2.0/24

          next

     

     

    config firewall policy 

        edit 10

           set src-zone INTERNAL

           set dst-zone EXTERNAL

           set srcaddr PORT1_LAN

           set dstaddr ALL

     

    etc....

     

    Ken Felix

     

    again most people do not understand zones or doing it wrong.

     

    Ken Felix

     

     

     

    bmduncan34
    bmduncan34Author
    New Member
    December 6, 2019

    Thanks Ken.  That's what I was asking after - kinda best practices.  You don't need to include interfaces that only have exactly the same security requirements in a zone.  I could easily have only two zones - an Outside zone with WAN interfaces etc, and an Inside zone that also includes my DMZ zone.  To manage traffic between my LAN segment and my DMZ I would just say both source and destination interfaces were Inside, but then apply the correct addresses for source and destination and I'd be fine.  Technically you could create only one zone, with one interface pair (Zone to Zone), and be still very secure, with the correct addressing/services combinations.  You would have one single flat list of policies, which might not be as easy to manage as breaking things up to different interface pairs like Inside-Outside, Outside-Inside, etc.  Does all that sound valid?

     

    Thanks very much!

    SecurityPlus
    SecurityPlus
    Explorer III
    February 7, 2020

    Working of a FortiGate 60E with 2 zones, Inside and Outside. Currently the Outside zone relates to the wan1 and wan2 interfaces, but only the wan1 is in use. The company wants to add a second wan connection for best speed and for redundancy. Can we simply configure and enable the wan2 interface to provide best speed and redundancy? If one of the wan connections fails will the traffic automatically be directed across the still working wan interface?

     

    In the past I have added the two wan interfaces to an SD-WAN. What are the pros and cons concerning using Zones vs. SD-WAN when using dual wan connections?

    emnoc
    emnoc
    New Member
    February 7, 2020

    SDWAN simplify the next-hop and routing and is more transparent

     

    Adding a 2nd interface to a zone need you to manage routing for next-hop and link detection of failures in the path

     

    50/50 on what is best it really depends on what you want. Zones is not relevant , since it does little to nothing with "routing", which is the key here

     

    SDWAN is the best and correct for load-balance, link sharing, link-fail-detection and better usage for the links like overload or spill over, imho

     

    Ken felix

     

    tanr
    tanr
    New Member
    February 7, 2020

    The reason I hadn't gone to SDWAN for our current setup is that we have some high bandwidth subnets I don't want using our backup ISP.  I want most users to be able to fail over to either provider transparently, but want these subnets to not be routed or allowed out the backup ISP.

     

    Is this now possible with SDWAN in 6.0 or 6.2?

    Terms & ConditionsAccessibility statement