Clarification regarding vsys function and network isolation

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Clarification regarding vsys function and network isolation

L1 Bithead

Hello,

After reading about and looking through documentation regarding vsys, and routing between vsys on the same firewall via use of external zones, as well as the vsys<>VR association, I have a few questions I would like to clarify if possible:

1. If I have two vsys that share one virtual router, by default, will they be able to send traffic between each other if there are routes in the routing table to get traffic between then (evia the fact that they both have directly connected layer 3 interfaces in that VR)? In the documentation, it looks like it says in this case you need to set up external zones with each vsys and have vsys visibility turned on, and then policy to allow one vsys to send from its internal zones to the external zone associated with it, and policy in the other vsys from to allow the same traffic from its external zone to its internal zone(s). Is this correct?

2. If I have two vsys associated with two different VRs, in this case it looks like I would need a route in each VR that points to the other VR as a next-hop, but ALSO the visibility between the two vsys as well as the matching vsys A internal zone>External zone A,  Vsys B External Zone>Internal zone vsys B policy as above. Is that correct?

Meaning, the only difference between the above two scenarios if if I need an explicit static route in the VR for each vsys pointing to the other VR as a next hop for the other vsys if they don't share a VR.

Where a lot of my confusion lies - I keep reading all of this documentation talking about how vsys is more of an administrative boundary, and does NOT provide routing isolation...but then it seems like you still need to provide visibility and policy between the two vsys even if they share one VR, which to me implies that there IS some level of network traffic isolation between vsys by default, and this is what is confusing me. What is the "vsys visibility" option really doing? What is is making visible between the two vsys if they share the same VR? Is it session information, or something else? This sticking point is very confusing, and I can't find any good documentation to clear it up.  Functionally I think I know and understand how to make the two scenarios and vsys<>vsys routing work, but I'd like to conceptually understand it as well.

Thanks for the help! 

4 REPLIES 4

Cyber Elite
Cyber Elite

The main thing to keep in mind is that the palo NGFW is a zone based firewall.

 

The most important aspect of building a session is determining the source and destination zone.

So, your VR's can be shared or assigned to an individual vsys, but the real barrier is at the zone level: to have vsys talk to eachother, you need to create the external zones and have one vsys allow traffic to the external zone and have the other one allow traffic from the external zone

 

the 'vsys visibility' setting actually allows a vsys to participate in the twilight zoney/dark matter 'external zone' that lives between the vsys. without this visibility turned on for a vsys, it does not have access to the 'external' zones

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

L1 Bithead

Thanks for that info.

When you use rules that look at source/destination IP and don't have any zones in them, at some level is the zone of the ingress/egress interface being taken into account?

Also with the vsys visibility - it allows them to participate in the external zones, but is there anything else it allows them to "see" between each other? Are they aware of each other's sessions or policy? If all that option does is enable the ability for the vsys to use an external zone, that seems redundant since if you don't have policy for the external zone, it won't allow communication into the vsys, is that correct?

Thanks again for the help - I'm trying to wrap my head around this and make sure that I understand all of it.

In the case of one company with the need to segment multiple zones/networks with no administrative boundaries, is there a reason why you wouldn't use one vsys with multiple VRs and policy around the zones in each VR to segment things?

The design I am looking at now, seems to have multiple vsys associated with one or more VRs and several zones in an attempt to create some kind of segmentation. I'm wondering though, could you not obtain that same result with one vsys and multiple VRs/zones and control things at the policy level? 

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

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

L1 Bithead

That does help a lot, thank you! So, even if two vsys shared the same VR and had routes to each other, without having visibility, they couldn't communicate, right?

  • 945 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!