single vsys to multi vsys setup
Showing results for 
Search instead for 
Did you mean: 

single vsys to multi vsys setup

L4 Transporter



So i have a cluster setup as a single vsys

I want to introduce a vendor GP setup - i have some vendor that want remote access to equipement and I want to allow them that access but   limited to just that.



I want to get around the accidental giving them more acces than they need. so I though tsecond vsys.


I presume I can then just set policies just for that vsys which will have 1 public ip and probaby a internal /29 so it can connect back to the main vsys and I can assign all the rules there. makes sense to me.


so how hard is it to turn on multi vsys and how do you route between vsys.. do I have to go out a port and back in a port ?






L4 Transporter
How about sticking with one vsys and having a dedicated (new) zone for the new global protect (portal, and gateway)? I known this does not answer your question.

I agree, adding a vsys for a simple GP setup is not necessary, it will use more resources than you need and potentially cost more as you may need to buy a vsys license.


As long as you have a proper rulebase and zoning you have nothing to worry about.

So don't the 5220 come with vssy licensing ?


My concern is I don't have a dedicated firewall team. so any mistake on the main rule set might open up 3rd parties to access all of my prod stuff.


as for zones. - sound good, but when i am routing between multiple PA's the zones are as effective. alot of my rules are based around ip networks (using names and tags)


i just thought it would make my life simplier to route the GP portal and gateway traffic through to a new vsys and have it take of the VPN and apply a set of rules for vendor's and then left it through to the main vsys. which would just have a rule saying allow.


I'm think linux style chains. be nice if I could say, if in interface is == <inf> then jump to these policy rules.





I'm a fan of the KISS principle. In this case I agree that just a zone is the better option. The only reason I would create a vsys would be if the vendor needed to co-manage the PAN. 


Remember that the security policies can be very specific:


Source zone = GPVPN, Source User=Vendors Users ID, Destination zone=Vendor equipment, destination IP=Vendors equipment IP's, Applications, and make sure you scan for threats/vulnerabilities with security Profiles.


Even if you have the traffic going over multiple PAN's, routers, switches, this PAN will control everything based on the policy you set. Also make sure its high enough in the list so it takes affect prior to any other policies. Then have a policy under it where the source user has a deny all so there is nothing else they can do.


Hope that helps.

Yes i understand. But I diss agree with the simple zone.


So for example if my pa cluster that has my vendor GP and the new zone vendor GP. send packets destined for another location and a new cluster


on the new cluster it doesn't know about the new zone - that packet (my understanding), gets the zone if from the in interface of that cluster. The 2 things I can use are who (userid and group) and source ip.


a lot of my rules are based around if you come from an internal company ip you are allowed access.


now I have to give the VPN an internal ip range .. so it might accidentally get extra access unless i double check all of my rules and make sure whom ever add / modified takes that into account.



having said all of that, I am sticking with the 1 vsys, I will just have to audit my rules :)



Auditing your policies is always a good idea/best practice. You can always setup an alert when a config change is performed. I have this in case another admin makes a change so I can review it for correctness.



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!