it's bad practice creating rules without zones 😉
but yes, zones are still used, they are part of the session in the session table
the visibility only opens up the 'space' between the vsys to communicate, they're not made aware of eachother's sessions, they don't have access to eachother's policies
without visibility between vsys1 and vsys2, they won't be able to communicate via the 'external' zone. if you enable vsys1 and vsys2 visibility, but don't add vsys3, then vsys3 will still not be able to use external zones to get to either. if you then also enable visibility between vsys1 and vsys3, these 2 will be able to communicate as well, but vsys3 and vsys2 will still not be able to communicate (hope this makes sense)
Now, with visibility between vsys1-vsys2 and vsys1-vsys3, the security rules will still be 'external'. so each vsys knows it's throwing things into the abyss, but the underlying system decides if this access is permitted
vsys are a tool to segment further, but a single company could indeed simply use multiple VR's to segment networks. The advantage of vsys is that you get separate sets of rules/nat etc, so less room for error
IHAC that has 1 vsys for their 'guest' network for sanitary reasons, a vsys for their DMZ environment and a vsys for their internal networks, DMZ and guest vsys have very strict and very few security rules, the internal one has hundreds. The multi-vsys setup also allows regular admins to make changes to the internal security rules, but they're unable to touch the DMZ or guest vsys. If you're a small team that wouldn't matter
hope this helps
T
... View more
