SmartMove - First impressions

[Iain_King]

Currently doing a Juniper SRX migration and looked at doing a conversion using smartmove.

Some somewhat formatted information below. The results are pretty good so far; there is definitely data I can use (object creation and so on). Most of that fairly easy to script from the raw configuration files anyway. 

This is a good start for smartmove, but it's not exactly perfect (and I probably wouldn't rely on it). I'll keep commenting as I get on. 

First pass (including NAT checkbox) fails with:

Unselected "Convert NAT configuration" and conversion succeeds. NAT's will need to be conducted manually.

// quick and dirty review below

Scripts generated are two-fold (objects.sh and policy.sh).

Objects.sh does a whole lot of the below with the address-book:

echo 'create host [xxxxxxx] with ip-address [1.2.3.4]'
cmd='mgmt_cli add host name "xxxxxxx" ip-address "1.2.3.4" ignore-warnings true -s id.txt --user-agent mgmt_cli_smartmove'

echo 'create network [1.2.3.0_24]: subnet [1.2.3.0] mask [255.255.255.0]'
cmd='mgmt_cli add network name "1.2.3.0_24" subnet "1.2.3.0" subnet-mask "255.255.255.0" ignore-warnings true -s id.txt --user-agent mgmt_cli_smartmove'

Does in fact create zone objects

echo 'Create Zone Objects (x6) '
echo 'create zone [Trust]'
cmd='mgmt_cli add security-zone name "Trust" ignore-warnings true -s id.txt --user-agent mgmt_cli_smartmove'
run_command
echo 'create zone [Untrust]'
cmd='mgmt_cli add security-zone name "Untrust" ignore-warnings true -s id.txt --user-agent mgmt_cli_smartmove'
run_command

Create's a bunch of duplicate services:

echo 'create tcp service [junos-ftp-data]: port [20]'
cmd='mgmt_cli add service-tcp name "junos-ftp-data" port "20" ignore-warnings true -s id.txt --user-agent mgmt_cli_smartmove'

echo 'Create DCE-RPC Service Objects (x21) '
echo 'create dce-rpc service [junos-ms-rpc-epm]: interface-uuid [e1af8308-5d1f-11c9-91a4-08002b14a0fa]'
cmd='mgmt_cli add service-dce-rpc name "junos-ms-rpc-epm" interface-uuid "e1af8308-5d1f-11c9-91a4-08002b14a0fa" ignore-warnings true -s id.txt --user-agent mgmt_cli_smartmove'
run_command

Policy conversion creates a large bunch of sub-policies #drop rules etc. 

echo 'Layers: Creating 20 sub-policies'
echo 'create layer [Trust_to_Untrust_sub_policy]'
cmd='mgmt_cli add access-layer name "Trust_to_Untrust_sub_policy" add-default-rule "false" ignore-warnings true -s id.txt --user-agent mgmt_cli_smartmove'
run_command
echo 'Add rules to layer Trust_to_Untrust_sub_policy'
cmd='mgmt_cli add access-rule layer "Trust_to_Untrust_sub_policy" action "drop" track-settings.type "Log" position "top" name "Default action rule" ignore-warnings true -s id.txt --user-agent mgmt_cli_smartmove'
run_command
echo -n $'\rrule 1/41 '
cmd='mgmt_cli add access-rule layer "Trust_to_Untrust_sub_policy" source "any" destination "any" service "any" action "drop" track-settings.type "Log" position "top" name "default-deny" ignore-warnings true -s id.txt --user-agent mgmt_cli_smartmove'
run_command

[Robert_Decker]

Hi,

Thank you for sharing your impressions and experience with us. Your feedback is very important. Please keep us updated as you progress with the tool.

1. The error during the NAT conversion is due to some configuration data mismatch, I'll check tomorrow the source code and redirect you to the problematic configuration. There is no reason to manually convert the NAT data.

2. The tool creates Zone objects and later uses these zones for policy creation.

3. Can you please be more specific regarding the duplicated services? Juniper services duplicated? Check Point services?

4. The converted policy is zone based (according to the source and destination). Each zone to zone flow is converted into an inline layer. There is no other way to accomplish the conversion from Juniper to Check Point architecture. In addition, management access rules are created at the top of the rulebase, if required due to Juniper configuration.

For more information, notes, instructions and limitations regarding the tool, you can refer to our public sk - sk115416.

Robert.

[Iain_King]

Quick update, 

Attempted importation today.

After R80.10 management station stand-up the API service didn't automatically start. This can be started by command -  'api start'.

After that the object import script largely succeeded (relatively smooth, including DNS name objects etc), lots of debugging outputs (good for me).

There were some errors noticed so far:

// This is obviously not a correct group.

create network group [_Err_in_service-line_3318]: 0 members

//

After completion:

//

---------------------------------------------
Time: [16:01:49] 17/4/2018
---------------------------------------------
"Publish operation" succeeded (100%)
tasks:
- task-id: "01234567-89ab-cdef-9c58-d5643421088e"
task-name: "Publish operation"
status: "succeeded"
progress-percentage: 100
suppressed: false
task-details:
- publishResponse:
numberOfPublishedChanges: 40
mode: "async"
revision: "66d14c4c-2bd9-4247-8c49-2fc3b3819e61"

message: "OK"

Some objects were not created successfully.
Check file failed_objects.txt for details.

//

The failed_objects file contained half a dozen objects which did not succeed.. these were mostly service objects but also host objects which had duplicate / non-unique names.

The Policy import provided a lot less text output with a count up of rules being created into sub-policies/layers. There were some errors, but nothing major (half a dozen rules).

The results in the policy are that it creates lots of rules with zones as source and destination, actions for these zones are sub-layered policies. 

To those familiar with <R77.30 the policy will probably be difficult to read and understand, zones are tied to interface configurations (in a similar location to anti-spoofing). Every interface will need to be tied to each zone created. 

If the replacement hardware received arrives on R77.30.. I will probably build on R77.30.

I am very, very skittish of commissioning this into production using R80.10 without significant QA/testing. Experience has taught me to be very wary about new versions of anything in checkpoint.

-- Iain

[Iain_King]

Feel free to contact offline to discuss specifics (xml), I'm happy to open a ticket about it if needs be.. but would prefer to bypass L1. 

[Robert_Decker]

Hi Iain,

Thank you for your feedback.

If you follow the instructions in sk115416, you should know that the migration process is done in several steps.

The first and most important is the verification - you get an output html file and detailed reports with warnings and errors that you must address before you progress to the final migration step.

For example, the _Err_in_service-line_3318 object is an alarm for you that something is wrong with your conversion.

You should address all errors before the migration step! Apparently, you did not.

As the tool description states, it is for R80 based security policies. This means that it heavily uses inline layers. I've also explained why in my reply above (which you did not address at all...). You should forget the R77 jargon when you use this tool.

Errors during the final import on duplicated objects is expected, as Juniper database has objects with the same name as Check Point database. You Should fix this manually.

Migration from one vendor to another is not just click and play. It is a process. You cannot skip steps during this process. This tool is to assist you along the process and shorten the fully manual process from weeks to few days at most. Follow the instructions from the beginning to the end, address all the output reports, do not skip steps. Then you will not need to complain that you wary about check point software.

And BTW, this is not an official Check Point release, it is an open source tool with full source code on GitHub, for our community benefits. For any discussion, question or clarification, you can post here and we'll assist.

Robert.

[Iain_King]

Yep,

Smartmove has probably saved me about 2 days of effort so far (thanks!). Don't thank me for feedback if you don't want honest feedback. It's never all good and I'm trying to be as constructive as I can, while being honestly objective. I haven't been able to get the NAT working at all and there are errors which I've detailed. It's not perfect, but it's been helpful.

Our boxes arrived R80.10 - we will be implementing R80.10 (g-d help us!)

Anyone who is strident about checkpoint QA doesn't have a lot of experience with it. One only needs to look at the release notes for Jumbo HFA's version after version to see the bugs you were living with that you didn't know where there until after they were fixed.

Take_103 JHFA is available on request. Do not install Take_91. 

Things like this are not uncommon, I've been working with FW1 since v4.1.. moving to a major revision in a haphazard fashion isn't smart. I've seen lifecycles at major corps over 6 months for minor revision upgrades.. major revisions requiring similar or more timelines. Moving from R65 to R67, R70 to R71, 4.1 to NG, NG to FP2.. just ask anybody who worked with large fleets about how these types of migrations typically have gone. It's natural to be wary of moving between major revisions (and to wait until it's fairly mature so only early adopters suffer).

There's lots of customers that are unlikely to consider move until 80.20 and hope that it comes out with time to test before R77.30 EOS comes next year. Let's just be honest about it.

I've taken to commenting and providing feedback on all checkpoint interactions where feedback is requested.. I have received relative hostility more often than I would like though! 

Thanks,

Iain.

[Robert_Decker]

Dear Iain,

Believe me, I do appreciate your input, the constructive parts of it. And there are many. But it seems that you concentrate mostly on highlighting negative parts. And again, you do not address what I wrote and explained about the tool and the questions I asked. I asked about objects duplication - you never answered. I asked if you followed the instructions and read the reports before the actual migration - you do not answer.

I'm not talking about other software, we are talking about this specific software, which Check Point developed for the community, delivering full source code for the public, free of charge, and provides support here in this community, free of charge - no support tickets and no L1 escalations.

Do you expect this tool to make magics and be fully automatic? There is no such tool, even not from the competitors. Migration is a very hard process and this tool is aimed to assist and shorten the process. You just need to follow the instructions and address the output reports. If there are bugs or something doesn't work as expected, we are here to assist and fix bugs. Free of charge.

Again, thanks for your input, really. I'm here to help.

Robert.

[Iain_King]

Now that I have a bit more time (deployment from project kick-off to production cut-over in 10 days); this was a bit rushed.. but everything is working. We did deploy on R80.10 T103. I'll respond inline to your queries:

1. The error during the NAT conversion is due to some configuration data mismatch, I'll check tomorrow the source code and redirect you to the problematic configuration. There is no reason to manually convert the NAT data.

I didn't have time to work on it.. there were only about a dozen NAT rules in total to migrate (half of them hide behind gateway) so it wasn't a big deal to do manually (less time than to assess the script handling and resolve that).

2. The tool creates Zone objects and later uses these zones for policy creation.

Yes, I was mentioning this because it's a first impressions. The context of my post is that I'm reporting on the script from having never seen it before and giving a first impression for those who haven't used it before (like me). It's important for users to know .. because they will need to specify zones per interfaces to match .

3. Can you please be more specific regarding the duplicated services? Juniper services duplicated? Check Point services?

Yes, duplicate objects (objects which share the same ports already used by juniper ports) are created in the policy, these need to be manually pruned afterwards. 

These aren't criticisms of the scripts, they are just stated observations.

4. The converted policy is zone based (according to the source and destination). Each zone to zone flow is converted into an inline layer. There is no other way to accomplish the conversion from Juniper to Check Point architecture. In addition, management access rules are created at the top of the rulebase, if required due to Juniper configuration.

Yes, No problem there. It worked rather well.. I ended up collapsing a couple of the interfaces into the same zone for ease of use. I'm still getting to grips with how packets are being matched by zone.. relying on logs a lot. There were some rules that had to be moved to different zones afterwards; this is likely due more to my cleaning up than anything else.

[Tomer_Sole]

Hi Iain,

I'm pretty sure all of Check Point is very happy with the opportunity that this new CheckMates platform gives for customer feedback. Please continue sharing your views. When we sound hostile it's because of love

The way I see it, there are 2 concerns:

1. Juniper migration to Check Point using SmartMove uses a new concept to Check Point, but something all of Juniper's customers are accustomed to - security zones. 

2. Quality questions with latest Jumbo Hotfix which bring memories of previous Check Point releases. 

I want to differentiate between the two. 

SmartMove issues

Any quality issue - we will fix. 

We hope that the detailed conversion log can help you assure that the conversion works as expected and assure your confidence with the tool. Also, the tool is open-source. So you can get answers to any question that you have about which commands are used and which logic is applied.

The purpose with SmartMove was to help Juniper admins feel right at home with Check Point. The somewhat down side means that Check Point admins migrating from Juniper may want to learn the new policy architecture benefits of R80.10 which are inline layers. We are going to be here to help with this. Layers in R80   Policy Management   

R80.10 and quality

I will branch this part if you have more questions:

R80.10 comes after 1 year of an Early Availability program where customers used the product in production. April 2018 is 11 months after GA and we see very high adoption rates of the new release in production. We haven't had this fast adoption rate with our previous releases in a while. R80.10 Security Management is a minor release after the major R80.  QA has changed with R80.10 bringing both larger coverage of each jumbo installation and a combination of automatic tests and manual usability tests. R80.10 Security Management by itself is a stability upgrade - the backend database is no longer composed of flat text files, but includes industry databases as well as validation layers of the Check Point software, which prevents from incorrect values or corruptions to occur. 

So I wouldn't call R80.10 an "early adoption" at this point.

This doesn't justify any quality issues that are discovered. The downside of an open community platform is that they bring quality issues to light faster than before. And counting online complaints, that might create an apple-to-apple perception of old releases without an open community platform to this one.. 

If you want to assure confidence with your environment and R80.10 be sure to use R80.x Upgrade Verification and Environment Simulation service  

I hope you will find many features with R80.10 that you want to upgrade to - and not just because your appliance nears end of support - I picked my favorite 10 but there's more:

• Parallel work
• REST API
• X3 time faster to do everyday operations – rule logs pane, where used + replace all, smart pickers, work on policies side by side, gateways overview
• New web-based real-time SmartEvent
• Validations prevent you from publishing your changes
• IPS automation with Tags and Revision Control
• Policy architecture and role segregation capabilities with Layers
• Gateway acceleration improvements
• Faster install policy verification process
• Redesigned and improved Management HA

[Iain_King]

Thanks for the links, I will read them.

I didn't get enough time really to read the source for the smartmove tool and take my time with it, like many in the trenches we need to meet schedules and any reduction in manual application is welcome. This tool saved me a lot of time writing dbedit scripts in R77.30 or manual object creation and reduced human error considerably. 

So far, I'm pleased with R80.10 (more than I expected). I feel a lot more comfortable deploying it now that I did a week ago. I'd be a lot happier with a greenfields deployment over a migration generally for any new product.

The changes are substantial enough for this to be almost considered a new product. Those things in addition are just as important as those things removed.. it's going to take me a while to get to grips with the backend changes (I can see lots of sqlite, postgres, java things going on and not a lot of documentation on that. Time will tell how it handles these databases as they grow. It took a long time to get syslog support into checkpoint (decades but now gone), it took until R77 to publish documentation on a lot of command driven features (that admins have known about in secret for a long time) and it took a long time to dump some of the antiquated mechanisms and add modern things.. there's still a lot missing (like a working package management system) but I'm as optimistic as a cynic can get, I guess.

Iain.

[Tomer_Sole]

More resources for getting started (because you wrote Postgres and Java, sqlite is gone now): R80.10 Architecture Overview  (we plan to post short videos about the architecture soon)

Some resource about Getting Started that I usually send to people:

- R80.10 SmartConsole Security Policies View | Threat Prevention - YouTube 

- R80.10 SmartConsole Gateways, Logs, and Manage & Settings Views | Security Management | Tech Bytes -... 

- R80.10 Policy Management - Permissions per Layer  

- R80+ Change Control: A Visual Guide 

- Leveraging the R80.10 API to Automate and Streamline Security Operations 

With so many partners and individual contributors pitching in, this is probably already the most documented version we've ever had...