In which cases would you use VSX?

[AlekseiShelepov]

Hello everyone.
I would like to hear your opinion and thoughts on the following topic.

Under which conditions the use of VSX on a cluster would really improve things? When would you prefer to use VSX over a usual setup? In other words, where is the line after which you decide "ok, this must be a VSX setup"?

The reason why I am thinking about this is that I cannot really see a lot of options for myself to use a VSX. I believe that in many usual cases adding VSX would just complicate things. VSX has some limitations, there are some additional things to be taken care of during operations like upgrades or migration, it should require additional hardware resources, as well as additional training of administrators.

Of course, VSX can bring several positive effects, which could weight out everything else (cost saving, flexibility, ease of adding new firewalls). But in my opinion this would work for only very few specific cases. 

I can see two options when most probably I would use VSX:

1. One of the cases when VSX could be preferable is when your company is a service provider and needs to support similar services for many customers. It would mean the you need to have many similar firewalls in the same data center, but they also must be separated from each other - own policies and objects, administrators, logs, etc.

So, many similar firewalls for different customers, separated from each other. It will help to minimize cost and time for adding a new customer to the environment.

2. The second case is when you are working in a quite big company which has multiple appliances for different purposes - external/perimeter firewall, VPN and mobile access appliance, internal firewall, separate firewall for server networks, etc.

One company with multiple firewalls for different purposes. It most probably would save quite a lot of money on appliances and their support contracts and would add possibilities to create VS for new purposes without big changes.

But would it be better to use VSX for a new VPN-only gateway for example? Or when you have only external and internal firewalls in your network? What about when you replace your old almost end-of-life internal firewall to a new cluster and besides of that there is only a separate VPN gateway?

[Alex_Rozhko]

I understand, but isn't same can be accomplished with sub-interfaces?

[Vladimir]

You cannot have different policies for different sub/interfaces of single gateway or cluster. Only one policy package could be enforced on non-VSX appliance or cluster.

This policy package will have same administrators and thus is not suitable for multi tenant implementation or segregation by security domains.

Vladimir Yakovlev

973.558.2738

vlad@eversecgroup.com

[Alex_Rozhko]

Even if you define each sub-interface as zone? With its own spoofing, rules, etc..?

[AlekseiShelepov]

Zones are not necessary in Check Point policies. You have different spoofing group for each interface without VSX. But you cannot install two policy packages on one logical gateway. You cannot connect one logical gateway to several domain management servers to have totally separate management databases (rules, objects, admins) for each customers/zones. You cannot have different blades enabled/disabled for different customers/zones. You cannot have different routing tables.

This is why we need VSX - we can have several logical systems on one physical device. So, you could have one VS in bridge mode with firewall doing some Geo Policies and checking traffic by IPS. You could have another VS with very strict firewall rules for one part of network, with enabled Anti-Virus, Anti-Bot, Application control blades. You can have another VS for Mobile Access blade. One VS for Customer-1 and one VS for Customer-2 separated from each other.

VSX is needed not for segmentation of just network, but for segmentation of bigger entities - functions, customers, zones (as in production traffic zone, test traffic zone, etc.).

[Alex_Rozhko]

Aleksei,

in your experience, did you use VSXs in clustered configurations like HA or LS? Did you use dynamic routing per VSX or per VS in either configuration? or everything was static? Did you use subinterfaces per VS or physical interfaces of the hardware? What hardware did you use?

[AlekseiShelepov]

The thing is that I don't use VSX at work anywhere, so don't have experience with it in production. There were some plans to implement VSX gateways, but we decided not to use it in our case. This is where my initial question came from.

[Alex_Rozhko]

Oliver,

reading this blog again, very interesting stuff. Can you provide visual map like Aleksei did at the beginning of this post of such microsegmentation, you had to deal with. It will be cool?

[HeikoAnkenbrand]

I would use VSX on R77.30 to use more VPN cores. Used this often on 23K or 61K systems. With R80.10 this doesn't matter any more, because it is MultiCore capable.

[Louis_Chorizo]

It's an intresting idea to use more VPN cores of our R77.30. I hadn't thought about it!

Nice

[Petr_Hantak]

After my last 5 years’ experience, I must say that I'm fan of VSX. Of course as you read most probably in this thread already, it is important to find suitable and reasonable setup. In our company we decided to segment customers logically based on the industry are. In case there are no special needs like extra security, much customized configuration or large setup, then customers have opportunity to use our "shared" VSX clusters for their virtual firewalls. It could give you nice and cost effective product.

BUT there are negative factors as well:

•  Software upgrades are complicated to prepare and manage. It is always much more time consuming against physical gateway (but you upgrades many customers/services together). It could be difficult to find suitable change window, but it is process topic.
•  We are using external BGP quite often and I must say that the dynamic routing and routing daemon on Check Point is still painful stuff. Since R77.30 it is more stable and synchronization works perfectly.
•  You should also plan your environment carefully as well. For example, during implementation nobody knows how many VSYSes and how big we'll want to use on on 12400 cluster. Therefore, we decided for maximum VSYS configuration and configure internal network suitable to it. After some time there we had there VSYS for one customer who wanted to add more interfaces than internal subnet allowed (it was 64 interfaces per virtual system for us). I must say that the changing of internal subnet size is always with quite long break unless you have spare devices where you can transfer configuration.
•  VSLS or simple HA. VSLS is nice, you should just observe load there a little bit. In some factors, it could be limiting especially when you need to use some non-standard features as source based routing. This is possible on HA setup only.
•  Virtual switches and virtual routers - here I think switches are perfectly fine. Virtual routers? From my experience, it is better to avoid them in case it is possible. Rather prefer physical router. It is hard to do some troubleshooting on it in case you need and dynamic routing could be painful on it (even 3 different TAC engineers were so confused with investigation one issue there so much that we rather implement different solution).
•  Performance tuning when you have bigger load on particular virtual systems. This is something with which you must count and tune it if needed (connection table limits, assigned cores, core distribution, multiques...)

In conclusion, when you will invest time to collecting of requirements, make suitable design and implementation then VSX is nice and dynamic solution.