Yes, another Zones question

[bmduncan34]

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.

[Kenundrum]

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]

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 zoneedit EXTERNALset interface WAN1endconfig system zoneedit INTERNALset interface PORT1 PORT2end  config sys int     edit PORT1          set ip 10.1.1.1/24    next     edit PORT2          set ip 10.1.2.1/24end  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]

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!

[boneyard]

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.

[emnoc]

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

[SecurityPlus]

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]

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]

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?

[SecurityPlus]

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?