VSX is pretty cool as VMware is cool. You can spin up new firewalls in a right-click and have them running in minutes vs dealing with ISO installs and physically installing a system.
Downside: Eggs In One Basket
Obviously if the VSX chassis has an issue, then all VSs inside of it are impacted. Like VMware. If the host has problems, then all the guests have problems. Like marriage, if the wife is not happy…the man is not happy.
But I diverge.
So I am creating a list of VSX design considerations to think about when deploying VSX. I’ll update as life goes on. These are mostly related to MDM, haven’t thought about SmartCenter:
1) Put the policies for all your VSX gateways/chassis in a single domain (VSXDOMAIN) that only admins can get to. These policies are pretty simple like ssh, web, control connections. This way some newbie can’t modify chassis related parameters and rules that impact the whole chassis. You can also then assign specific administrative permissions to VSXDOMAIN so that only superduper users have access to it. Also prevents newbies from doing an “Install Policy on All Gateways” and installing some random policy from one of the VSs onto your VSX gateway. Boy would that suck or what?
Or maybe more out there but has happened, is that when you mix VSX and VS config information in one domain, then the underlying file system is also hierarchical. If you delete the VSX domain file system, you delete all your VS config information. This is not true if you separate them.
2) Propagate routes: Note that when you update routing tables in SmartDashboard when you save the policy, the routes are immediately injected into the running VSs even if you don’t do a SAVE. So you might want to think about limiting the propagation of routes if it will be a problem.
Check out this listing of files that changed after I saved the dashboard. THe files contain mostly routing information. These files are also updated with dinking with interfaces and spoofing. Oh yeah, in theory all you have to do is a “Save Policy”, but in reality you probably have to do a push policy. For example routing is suppose to be independent and not need a install policy, but you may run into spoofing issues and so you have to push policy to make it all work. Interfaces and spoofing you have to push policy to make work. I would say for major interface updates like bonding, vlans, give it the old reboot too.
3) VSs are attached to VSX gateway objects. This is a permanent binding, you can’t undo. If you need to rename the VSX gateway object, you basically can’t. You have to have downtime on all VSs as you re-create VSs on new VSX gateway objects.
4) Think about the things that are shared; CPU, time, file system like the /etc directory. All these shared items impact the whole chassis. So if someone deletes the /etc directory or a critical file like resolve.conf, you lose the whole platform. So create least privilege around who can modify these shared items.
5) Along with #4 above. Arp tables. VSX interacts with many clients so it creates huge arp tables. Check out sk43772.
6) Along with #4, watch out for SmartMonitor, cpstat fw -f os, top, fw ctl pstat. They all lie about CPU utilization. VSs share CPUs, but the reporting tools only report on the average of ALL the CPUs. If the system is configured to use 2 of 12 CPUs, you get the average of all 12 even though the 2 are running at 100%. So your average will be say…. 80% idle.
7) I guess the biggest issue is scope. VSX is fantastic for small little used firewalls.Major gateways with 10s thousands of users or major ecommerce gateways….no. Why? 1) Shared platform – Any virtual system shares the platform. Eggs in one basket.If your lab firewall all of a sudden overwhelms the CPU, then your ecommerce firewall is toast. If an admin types in the wrong command, toast. If you add interfaces and something goes wrong, toast. 2) Going backwards – VSX is really cool, but it is difficult to go backwards. Yes you can delete virtual systems….but you sit there with your fingers cross praying to gods you didn’t even know exist. And if it blows, get ready to hand edit internal databases. I’ve done it. Sucks. Check Point HAS to fix their DMS database from flat files to a SQL lite database. Right now an object name appears in 100 different places. If the delete or modify goes wrong, it only updates 50 of the 100 and then you hunt for the rest. And pray none are in a binary file. 3) Upgrades. If you never done a VSX upgrade then you won’t appreciate what it takes and how delicate it can be. You really don’t want to do this on a $1million/minute gateway. With ANY virtual system. Just one mans opinion.
That’s what I know for now, stay tuned I’m sure this will get updated as life goes on.
dreez
DreezSecurityBlog 