Hot!Yes, another Zones question

Author
bmduncan34
Bronze Member
  • Total Posts : 30
  • Scores: 0
  • Reward points: 0
  • Joined: 2017/07/05 10:33:11
  • Status: offline
2019/12/05 08:50:39 (permalink)
0

Yes, another Zones question

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.
#1

11 Replies Related Threads

    Kenundrum
    Gold Member
    • Total Posts : 158
    • Scores: 21
    • Reward points: 0
    • Joined: 2008/05/15 10:25:50
    • Location: Rhode Island, US
    • Status: offline
    Re: Yes, another Zones question 2019/12/05 10:35:38 (permalink)
    0
    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.
    post edited by Kenundrum - 2019/12/05 10:39:40

    NSE4
    Some FGT500Es, 500Ds, 60Ds at work
    FWF60E, FWF80CM at home
    #2
    emnoc
    Expert Member
    • Total Posts : 5748
    • Scores: 373
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: offline
    Re: Yes, another Zones question 2019/12/05 16:07:30 (permalink)
    0

    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
     
     
     

    PCNSE 
    NSE 
    StrongSwan  
    #3
    bmduncan34
    Bronze Member
    • Total Posts : 30
    • Scores: 0
    • Reward points: 0
    • Joined: 2017/07/05 10:33:11
    • Status: offline
    Re: Yes, another Zones question 2019/12/06 11:52:50 (permalink)
    0
    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!
    #4
    boneyard
    Gold Member
    • Total Posts : 211
    • Scores: 10
    • Reward points: 0
    • Joined: 2014/07/30 11:15:18
    • Status: offline
    Re: Yes, another Zones question 2019/12/07 03:11:08 (permalink)
    0
    it is a balance thing. like Kenundrum i always use zones with a one on one mapping to an interface for flexibility. then combine interfaces in one zone mainly on doing pretty much the same thing, i.e. two wan interfaces (although sd-wan interface is messing with that now), multiple client networks, add a second VPN tunnel.
     
    to combine almost all interface in one zone feels like a quick solution but not a real pretty one, you loose some of the logic zones bring and loose a good overview of your rule based in my opinion. you also have to be much more careful with rules blocking part of the traffic.
    #5
    emnoc
    Expert Member
    • Total Posts : 5748
    • Scores: 373
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: offline
    Re: Yes, another Zones question 2019/12/07 06:28:54 (permalink)
    0
    Zones have to be thought out and src/dst address in the policy still controls the traffic flow. The only issue with zones, once you go zone you can NOT uses in the policy if it is in a zone. CHKP and Forcepoint bends this restriction.
     
    FWIW, I've seen very good zone deployments and very bad ones also.Most are deploying bad design and or deploying zones with made forethought but that's my opinion.
     
    I've use zones maybe 30% of the time, unless it's a PANW/JNPR migrations and in these 2 platforms it's 100% "zone" with no exceptions.
     
     
    Ken Felix
     
     

    PCNSE 
    NSE 
    StrongSwan  
    #6
    SecurityPlus
    Gold Member
    • Total Posts : 346
    • Scores: 4
    • Reward points: 0
    • Joined: 2014/08/11 18:41:34
    • Status: offline
    Re: Yes, another Zones question 2020/02/07 12:47:44 (permalink)
    0
    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?

    FWF30E, FG50E, FWF50E, FG60D, FWF60D, FG60E, FG60F, FG80E, FG100D
    FortiOS 5.2, 5.4, 5.6, and 6.0
    FortiSwitch FS-224E-POE
    FAP-221E, FAP-221C
    #7
    emnoc
    Expert Member
    • Total Posts : 5748
    • Scores: 373
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: offline
    Re: Yes, another Zones question 2020/02/07 13:39:32 (permalink)
    0
    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
     

    PCNSE 
    NSE 
    StrongSwan  
    #8
    tanr
    Platinum Member
    • Total Posts : 802
    • Scores: 36
    • Reward points: 0
    • Joined: 2016/05/09 17:09:43
    • Status: offline
    Re: Yes, another Zones question 2020/02/07 14:06:52 (permalink)
    0
    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?
    #9
    SecurityPlus
    Gold Member
    • Total Posts : 346
    • Scores: 4
    • Reward points: 0
    • Joined: 2014/08/11 18:41:34
    • Status: offline
    Re: Yes, another Zones question 2020/02/07 14:34:59 (permalink)
    0
    So if the firewall is currently using a zone called Outside consistenting of one interface (wan1), would it be best to build an SD-WAN and use the new SD-WAN in policies in lieu of the Outside zone?

    FWF30E, FG50E, FWF50E, FG60D, FWF60D, FG60E, FG60F, FG80E, FG100D
    FortiOS 5.2, 5.4, 5.6, and 6.0
    FortiSwitch FS-224E-POE
    FAP-221E, FAP-221C
    #10
    emnoc
    Expert Member
    • Total Posts : 5748
    • Scores: 373
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: offline
    Re: Yes, another Zones question 2020/02/07 16:41:38 (permalink)
    0
    A zone is a just a zone , and I'm like 99.99% sure you can't set a named "zone"  in a SD_WAN member, so this question is moot. Also for bandwidth you can control that within SDWAN with traffic policies
     
    You need to decide if you want SD_WAN? If not and you later decide you want SD_WAN you will have a lot of re-work in order to get to SD_WAN.
     
    Ken Felix

    PCNSE 
    NSE 
    StrongSwan  
    #11
    MikePruett
    Platinum Member
    • Total Posts : 702
    • Scores: 17
    • Reward points: 0
    • Joined: 2014/01/08 19:39:40
    • Location: Montgomery, Al
    • Status: offline
    Re: Yes, another Zones question 2020/02/09 11:07:28 (permalink)
    0
    SD-WAN works. Zones are incredibly useful. If you wanted to use Zones instead of SD-WAN for your outside interfaces you can. It is not as robust though as the SD-WAN capability and you are going to be doing a lot of policy routes and custom link monitors whereas you could just configure SD WAN Rules and Health Checks and have a lot more visibility from the GUI etc.
     
     
    Simple environments are great for zones. Especially if you have multiple inside interfaces and multiple outsides. I'm a big fan of INSIDE, OUTSIDE, and IPSEC for relatively simple setups. It keeps it simple from an engineering standpoint. Now, I have a state agency that manages all other state agencies. They have hundreds of interfaces. We use zones for this as well but they are created based on sub-agency,interface classifications, services, etc. It helps us streamline things and keep policy counts lower and easier to manage but it can get just as cumbersome if not thought out properly.
    post edited by MikePruett - 2020/02/09 11:10:54
    #12
    Jump to:
    © 2020 APG vNext Commercial Version 5.5