Skip navigation
All Places > General Product Topics > Appliances and Gaia > Blog

Hi,

 

We’ve announced in CPX Asia 2 new Security Gateways appliances: 6500 & 6800. The Check Point 6500 and 6800 are a new generation of high performance Security Gateways for the enterprise market segment. With the new 6000 series, enterprise customers can enable advanced threat prevention and inspect for threats within TLS encrypted traffic.

 

The 6500 and 6800 will be available in the Check Point Product Catalog from February 1st.

 

Datasheets are available for download now.

 

Support Links

 

With the introduction of the 6500 & 6800 we are taking the opportunity to simplify and accelerate our business processes.

These new products and all of their accessories are priced with significant discounts incorporated in their list prices. This shortens sales cycles and eliminates dependencies in discounting processes.

In addition we revisited how we offer our Security Gateways. Instead of dozens of tedious appliance SKUs, each model will be available in 2 simple configurations: base and PLUS. Both are equipped with our existing and well-known Next Generation Threat Prevention subscription for the first year. The PLUS option adds a richer hardware configuration; redundant components when supported by the gateway, SSDs and extra memory for additional connection capacity. The base option comes with Hard Disk Drive(s) and supports local management while the PLUS with SSD disk(s) does not.

 

With the ~50% price reduction in accessories there are also stricter discounting policies which are also incorporated into the Check Point Product Catalog.

 

I would like to take this opportunity and thank the many groups that were involved in the introduction of these 2 new appliances – R&D, QA, Finance, NPI, Product Infrastructure, Planning, Business Analysis, Legal – great Teamwork!

 

Feel free to contact me in any question or query regarding the 6500 & 6800.

Wishing you a successful and fruitful 2019.

 

regards,
Yaron Weiler
Security Gateways Product Manager
yaronw@checkpoint.com
+972-54-9222361

Remember the teasers about new Gaia features in EA (REST API and Dynamic CLI) ?

 

So, we are glad to let you know that both features are now available for download, and have public SKs with all relevant information :

 

Ender (REST API) - sk143612

 

Dynamic CLI - sk144112

 

Please, feel free to try them out, and let us know what you think.

 

You can use GAIA_TECH@MICHAEL.CHECKPOINT.COM  forum to ask questions and share your experience, so that more people will get the sense of those features.

 

We will be showing both features in upcoming CPX, with live demo in Tech Room. Let me know if you want to meet there and discuss specific use-cases or roadmap.

 

Hi.

 

Today I am preparing a small presentation for our next week inhouse-exhibition about CDT – version 1.5. During my preparations I was trying to refine a script that was executed on the gateways via execute_script. After the script was executed successful once, I was unable to run it again on the same gateway. Output tells me that execution was skipped. No hints in the documentation.

 

It took me some time fo find where the state of the execution was saved. The script was named install_cp-scripts.sh. The state of the script can be reset on the gateway with:

/bin/dbset installer:cdt:/var/log/install_cp-scripts.sh 0

Knowing this one could put a command into the deployment plan executing this for scripts to be run again. But I do not consider saving the state on the gateway the perfect idea for a tool designed to centrally manage gateways. In my opinion such state information has to be saved locally on the management server running the CDT. In that way you can change the state in the same place where you configure the rest of your deployment.

By all means, this has to be documented.

 

Another suggestion would be a possibility to define a $HOME where the CDT commands shall be executed on the gateway. Actually $HOME is /. That would not be my directory of choice.

Recently had a client test KVM / oVirt as an alternative virtual environment. During testing we noticed that ClusterXL was repeatedly failing or just not forming a cluster. The active member could not detect the standby members status.

 

Debug ClusterXL output

 

;28Aug2018 14:50:31.269123;[cpu_6];[fw4_1];FW-1: check_other_machine_activity: calling fwldbcast_died for ID 0;

;28Aug2018 14:50:31.269138;[cpu_6];[fw4_1];FW-1: fwha_notify_interface: IF_IP_BY_HANDLE(ffff81023de270c0, 1)=10.121.47.131;

;28Aug2018 14:50:31.269145;[cpu_6];[fw4_1];FW-1: fwha_notify_interface: IF_IP_BY_HANDLE(ffff81023d856440, 2)=10.121.34.131;

;28Aug2018 14:50:31.269151;[cpu_6];[fw4_1];FW-1: fwha_notify_interface: IF_IP_BY_HANDLE(ffff81023d54fc40, 3)=10.121.36.131;

;28Aug2018 14:50:31.369011;[cpu_6];[fw4_1];FW-1: check_other_machine_activity: calling fwldbcast_died for ID 0;

;28Aug2018 14:50:31.469934;[cpu_6];[fw4_1];FW-1: check_other_machine_activity: calling fwldbcast_died for ID 0;

;28Aug2018 14:50:31.570847;[cpu_6];[fw4_1];FW-1: check_other_machine_activity: calling fwldbcast_died for ID 0;

;28Aug2018 14:50:31.670768;[cpu_6];[fw4_1];FW-1: fwha_report_id_problem_status: State (DOWN) reported by device Interface Active Check (non-blocking) (ID 1 time 85773.7);

;28Aug2018 14:50:31.670773;[cpu_6];[fw4_1];FW-1: id_blocking_state: check (0) (1) (4) ;

;28Aug2018 14:50:31.670774;[cpu_6];[fw4_1];FW-1: id_blocking_state: check (1) (1) (4) ;

;28Aug2018 14:50:31.670775;[cpu_6];[fw4_1];FW-1: id_blocking_state: check (2) (1) (4) ;

;28Aug2018 14:50:31.670776;[cpu_6];[fw4_1];FW-1: id_blocking_state: check (3) (1) (4) ;

;28Aug2018 14:50:31.670778;[cpu_6];[fw4_1];FW-1: id_blocking_state: check (4) (1) (4) ;

;28Aug2018 14:50:31.670779;[cpu_6];[fw4_1];FW-1: fwha_report_id_problem_status: Blocking state (ACTIVE) not changed by state DOWN from Interface Active Check (ID 1);

;28Aug2018 14:50:31.670788;[cpu_6];[fw4_1];FW-1: check_other_machine_activity: calling fwldbcast_died for ID 0;

;28Aug2018 14:50:31.770675;[cpu_6];[fw4_1];FW-1: check_other_machine_activity: calling fwldbcast_died for ID 0;

;28Aug2018 14:50:31.870573;[cpu_6];[fw4_1];FW-1: check_other_machine_activity: calling fwldbcast_died for ID 0;

;28Aug2018 14:50:31.970513;[cpu_6];[fw4_1];FW-1: check_other_machine_activity: calling fwldbcast_died for ID 0;

 

From a testing point of view we looked at a number of things including moving the 2 members to the same physical host device. Nothing resolved this inconsistency. We finally were looking at the switching network environment and noted that the MAC's we were trying to communicate with were either not listed in the MAC address table or not pointing to where they should be.

 

Testing lead us to look at anti spoofing capabilities of oVirt. oVirt and for that matter most hypervisors KVM or otherwise enable an anti MAC spoofing rule to prevent one VM from taking over the traffic of another VM. In our case with clustering that is exactly what we wanted to happen.

 

From an oVirt point of view we removed the anti MAC spoofing rule from the cluster VM interfaces. At this time oVirt is in the process of adding a default setting to enable the Ant spoofing filter process. See this link for details: https://ovirt.org/develop/release-management/features/network/networkfiltering.html

Hi,

 

I would like to invite you to try out two new Gaia features which may provide a great deal of simplicity in day-to-day operation. You can find a short description below, followed by dates, available versions and contacts.

 

Both of them deal with the way we configure settings on Gaia gateways. We are used to tools like clish and WebUI, and in many cases we even need to switch to expert mode to set/get some of the gateway settings. These two projects are aimed to simplify and organize this.

 

  • Dynamic CLI

        

 

The idea is very simple – pull any expert command/script/binary to real clish command. But, unlike “extended command”, we are talking about real clish – with friendly syntax, auto completion, full RBA support (roles/features/users), history and more…

 

Example : instead of assigning admin privileges to the operator in order to run

 

#fw tab –t connections –f

 

Just stay in clish and type

 

>show security-gateway table connections formatted

 

And enjoy the auto completion (including the list of available firewall tables), help strings, and a peace of mind knowing that this operator will only be able to see the tables but not delete them, for example.

 

The feature brings in the infrastructure, the coverage of possible expert commands to be ported into clish is ongoing, and the list can be augmented based on what the field needs.

 

===========================================================================================

 

  • Ender (Gaia REST APIs)

                    

 

 

This one is a bit fancier – running a REST daemon on Gaia gateway, allowing remote configuration based on HTTP with JSON arguments and JSON response. Similar to existing Mgmt APIs, but this time covering any gateway configuration, any clish command, any expert command/binary or any flow combining a group of clish/expert commands in one URL.

 

Any sort of automation/orchestration or remote monitoring/debugging on the gateway (or Mgmt server) can be achieved with this feature over REST, including Ansible and Terraform support.

 

===========================================================================================

 

Cool, so how do I get it and when ?

 

Both of the features are now in EA, beta versions available (can be installed on top of R80.10 or R80.20). They come as a separate self-updateable hotfixes, and do not block the customer from installing JHFs on top of it (sweet, right ? ). We plan to release an SK with a downloadable package for each of the features by the end of this month - stay tuned.

 

Please, do not hesitate to contact Linor, Tal and myself for more details or if you want the EA version packages to play around with…

 

Cheers,

Kim

Hi, all.

 

Great news for our Cloud Guard and Open Servers customers : R80.20 Security Gateway with new Gaia based on kernel 3.10 is a GO !

 

We have completed the certification of public cloud (AWS and Azure) and new HP Gen10 Open Servers platforms.

 

The image will be available in Azure and AWS in a few days.

 

Performance improvement on kernel 3.10 based CloudGuard environments is ~300% comparing to current CloudGuard numbers !

 

We now support latest Gen10 HP servers as R80.20 gateways – and we will be adding more open servers soon.

 

The SK for R80.20 kernel 3.10 gateway with all the information and list of limitations is ready here - sk141173.

 

Thanks,

Kim