CPUG: The Check Point User Group

Resources for the Check Point Community, by the Check Point Community.


First, I hope you're all well and staying safe.
Second, I want to give a "heads up" that you should see more activity here shortly, and maybe a few cosmetic changes.
I'll post more details to the "Announcements" forum soon, so be on the lookout. -E

 

Results 1 to 14 of 14

Thread: Upgrade to 80.40

  1. #1
    Join Date
    2019-07-12
    Posts
    11
    Rep Power
    0

    Default Upgrade to 80.40

    Wondering if anyone has made the jump to 80.40 and is willing to share their experience. Any noticeable problems or issues as a result?

  2. #2
    Join Date
    2014-09-02
    Posts
    369
    Rep Power
    10

    Default Re: Upgrade to 80.40

    While you haven't said what version you're coming from, I say "go for it". Loads of new features and enhancements, and minimal fear/risk.

    We've updated numerous clients with very little issue - and nothing really worth note. It's currently the "recommended" version and becoming quickly adopted - at least from what I can see.

    I think my biggest (only?) early frustration was with a number of "missing" command in the Gaia CLI. As it turned out, CP had implemented what they call "Dynamic CLI", which extends the capabilities of CLISH by changing/moving commands in from bash/expert-mode (like fwaccel, cphaprob, cplic, etc.). While it took a bit of getting used to, it will eventually lead reduced need for leaving CLISH, giving most users a simpler CLI experience, and likely increasing security of the system a bit. It's discussed in sk144112.

    I'll skip a discussion of new features and reasons, as that's been covered well elsewhere (like here). I even did a webinar on "what's new" a couple of weeks ago. I should be able to send you a link to a recording via PM, if you'd like.

    -E

  3. #3
    Join Date
    2019-07-12
    Posts
    11
    Rep Power
    0

    Default Re: Upgrade to 80.40

    Thank you very much for the feedback! If you would please be willing to send a link to your webinar to me in a PM, I'd love to see it! At this time, I am looking to perform an in-place upgrade of two management devices and logging device from 80.20.

  4. #4
    Join Date
    2007-03-30
    Location
    DFW, TX
    Posts
    356
    Rep Power
    14

    Default Re: Upgrade to 80.40

    I upgraded my personal 2200 from R80.20 to R80.40 over the weekend. It has a 1.8 GHz dual-core processor, 4 GB of RAM, and a SATA SSD. Except for the SSD, it's pretty close to a worst-case scenario.

    All told, the upgrade took something like six hours, processor-bound. Memory consumption is up a hair, but not significantly. I wound up with kernel 3.10 and ext3 filesystems. I gather a clean install gives you xfs filesystems, which allows for larger volumes (potentially important for log servers).

    It looks like VSX has probably moved from VRFs to network namespaces. This system only has VRF/NetNS 0, but I only see network namespaces, and no entries in /proc for VRFs.

  5. #5
    Join Date
    2014-09-02
    Posts
    369
    Rep Power
    10

    Default Re: Upgrade to 80.40

    Quote Originally Posted by TheDroppedPacket View Post
    Thank you very much for the feedback! If you would please be willing to send a link to your webinar to me in a PM, I'd love to see it! At this time, I am looking to perform an in-place upgrade of two management devices and logging device from 80.20.
    Info sent.

    If you're only upgrading management devices, then definitely go for it. As always, just make sure you have [good] backups first - and take snapshots.

    -E

  6. #6
    Join Date
    2019-07-12
    Posts
    11
    Rep Power
    0

    Default Re: Upgrade to 80.40

    With the kernel changes and the partition changes that come with 80.40 (which I learned about in Eric's webinar), I was going to ask if there were any "gotchas" with an in-place upgrade. I am assuming the kernel will be upgraded in my case but the partitions will remain the same. (?) I really appreciate the feedback!

  7. #7
    Join Date
    2007-03-30
    Location
    DFW, TX
    Posts
    356
    Rep Power
    14

    Default Re: Upgrade to 80.40

    That would be my expectation. Kernels are easy to swap. It’s a single binary image stored on the disk. Point to a new one, done.

    Filesystems are much harder to swap (though not impossible; Apple recently replaced HFS+ with APFS on almost all devices with an OS update). They’re a big tree of pointers to individual blocks on disk, and most write the tree in subtly different ways. New filesystems are generally reserved for completely clean installations of an OS.

  8. #8
    Join Date
    2005-08-14
    Location
    Gig Harbor, WA, USA
    Posts
    2,499
    Rep Power
    18

    Default Re: Upgrade to 80.40

    Quote Originally Posted by Bob_Zimmerman View Post
    Filesystems are much harder to swap (though not impossible; Apple recently replaced HFS+ with APFS on almost all devices with an OS update). They’re a big tree of pointers to individual blocks on disk, and most write the tree in subtly different ways. New filesystems are generally reserved for completely clean installations of an OS.
    If it were a simple issue of changing the filesystem, it could probably be done.
    In this case, we're also changing the partition type.
    http://phoneboy.org
    Unless otherwise noted, views expressed are my own

  9. #9
    Join Date
    2019-07-12
    Posts
    11
    Rep Power
    0

    Default Re: Upgrade to 80.40

    Just as a follow up, I did complete the upgrade of our management appliances and logging appliance to R80.40. The process of creating snapshots and exporting them off of the appliances, as well as creating backups and downloading those, was more time consuming than the actual upgrade. I performed an in-place upgrade to R80.40 and then applied the most recent jumbo hotfix. Related or coincidental, these are issues we encountered in the upgrade process or as a result:

    - Had to reinstall the management database.

    - Customizations made to the crypt.def or implied_rules.def files will be overwritten in the upgrade process. If changes have been made to these files in the past, they should be backed up before upgrading for post-upgrade reference. My customizations had to be manually added back into these files on primary management (the changes synced). Depending upon your gateways, it may be necessary to make the changes to the same files in various other subdirectories in /opt.

    - Opening SmartConsole post-upgrade resulted in a "Certificate Revoked" failure. Needed to create a new certificate with the help of support.

  10. #10
    Join Date
    2007-03-30
    Location
    DFW, TX
    Posts
    356
    Rep Power
    14

    Default Re: Upgrade to 80.40

    Quote Originally Posted by TheDroppedPacket View Post
    - Customizations made to the crypt.def or implied_rules.def files will be overwritten in the upgrade process. If changes have been made to these files in the past, they should be backed up before upgrading for post-upgrade reference. My customizations had to be manually added back into these files on primary management (the changes synced). Depending upon your gateways, it may be necessary to make the changes to the same files in various other subdirectories in /opt.
    I try really hard not to make modifications to files like the table.def, implied_rules.def, and so on. This is why. Upgrades always wipe them out, and updates sometimes do as well. Rediscovering all that is no fun, particularly since upgrades are infrequent enough I'll forget all about them again by the next one.

    Glad to hear it went pretty well otherwise, though!

  11. #11
    Join Date
    2014-09-02
    Posts
    369
    Rep Power
    10

    Default Re: Upgrade to 80.40

    Quote Originally Posted by Bob_Zimmerman View Post
    I try really hard not to make modifications to files like the table.def, implied_rules.def, and so on. This is why. Upgrades always wipe them out, and updates sometimes do as well. Rediscovering all that is no fun, particularly since upgrades are infrequent enough I'll forget all about them again by the next one.
    This is also why such changes should be documented. I know that's not traditionally a favorite word among us engineers (or even in our vocabulary), but keeping a folder/document with "non standard" and/or "unsupported" modification/customizations can be invaluable at times like this.

    Could CP include those files/modifications in backups? Maybe, but often the upgrade process itself needs to make its own modifications/additions to said files, and has to have certain expectations/standardization. Check Point has always "allowed" a certain flexibility in allowing us to do cool, fun, and potentially dangerous stuff, but we do so at our own peril. They would essentially have to account for infinite possibilities, which would be impossible.

    The alternative would be to lock us out of making unsupported modifications. Look at Apple products - very slick and reliable (and easy to backup/restore), but often frustratingly limited, at least to the more "advanced" user.

    Here comes my usual [and maybe absurd] analogy: Would you expect your car's manufacturer to honor your warranty after installing a NOS kit and blowing out your engine?

    -E

  12. #12
    Join Date
    2014-09-02
    Posts
    369
    Rep Power
    10

    Default Re: Upgrade to 80.40

    One important afterthought (before someone else brings it up):

    This changes a bit if/when the customization in question has been at the direction of CP TAC (or other official Check Point channels). It should still be documented and tracked as an exception, but if the "standard" resolution is to modify something unusual, it isn't that unreasonable to expect that modification to be included in backups.

    Historically, as "solutions" like this become more common, they usually work their way into mainstream configuration. One great example would be "Capacity optimization". For years (especially back in the previous millennium - yes, I'm old) we would manually modify/increase the "maximum concurrent connections" limit on gateways by editing the value in the objects.c file - which always had the potential to be "undone" by an upgrade. Eventually, this became such a common mod (I can sometimes sound younger) that it worked its way into SmartDashboard - making it easier to both adjust and support.

    -E

  13. #13
    Join Date
    2007-03-30
    Location
    DFW, TX
    Posts
    356
    Rep Power
    14

    Default Re: Upgrade to 80.40

    Quote Originally Posted by EricAnderson View Post
    This is also why such changes should be documented. I know that's not traditionally a favorite word among us engineers (or even in our vocabulary), but keeping a folder/document with "non standard" and/or "unsupported" modification/customizations can be invaluable at times like this.

    Could CP include those files/modifications in backups? Maybe, but often the upgrade process itself needs to make its own modifications/additions to said files, and has to have certain expectations/standardization. Check Point has always "allowed" a certain flexibility in allowing us to do cool, fun, and potentially dangerous stuff, but we do so at our own peril. They would essentially have to account for infinite possibilities, which would be impossible.

    The alternative would be to lock us out of making unsupported modifications. Look at Apple products - very slick and reliable (and easy to backup/restore), but often frustratingly limited, at least to the more "advanced" user.

    Here comes my usual [and maybe absurd] analogy: Would you expect your car's manufacturer to honor your warranty after installing a NOS kit and blowing out your engine?

    -E
    Sure, but there's a great saying among programmers: the best code is the code you don't have to write. If you can arrange other things such that you don't need the modification, that's vastly preferable to making modifications and recording them in documentation someone can forget to update or forget to consult during an upgrade. It simply removes the possibility for error.

    As for the car thing, I would absolutely expect them to honor the warranty on my suspension, differential, probably transmission. In the US, Magnuson-Moss says they have to unless they prove the modification is the reason for the failure.

    Incidentally, this is also why "Warranty void if seal is broken" stickers are nonsense in the US. They're legal to apply for some reason, but breaking such a sticker absolutely does not void a manufacturer's warranty obligations.

  14. #14
    Join Date
    2019-07-12
    Posts
    11
    Rep Power
    0

    Default Re: Upgrade to 80.40

    Just for the record, the original crypt.def file customizations were at the recommendation of support in order to resolve a support case. (The troubleshooting of that issue occurred with a predecessor and I did not make the original changes.) The changes were documented and reapplied after the upgrade to R80.40. However, the changes needed to be made in additional crypt.def files in other /opt subdirectories in the new version. These additional requirements did not appear to be documented in the Check Point knowledge base. My support rep indicated that he was going to follow up on updating the appropriate SK article(s).

Similar Threads

  1. Time to upgrade! I am available for contracts to upgrade your Check Point Software.
    By security4it in forum Employment/Consulting Opportunities For Check Point Administrators
    Replies: 0
    Last Post: 2015-10-04, 12:58
  2. r65.70 upgrade --> r71.10 full connectivity upgrade issues
    By lordbigsack in forum Installing And Upgrading
    Replies: 1
    Last Post: 2012-01-13, 12:55
  3. Delayed R60 gateway upgrade after mangement/gateway combo upgrade to R75
    By netstorm in forum Security Management Server (Formerly SmartCenter Server ((Formerly Management Server))
    Replies: 3
    Last Post: 2012-01-05, 09:41
  4. licence upgrade and hardware upgrade
    By symon in forum Licensing
    Replies: 5
    Last Post: 2011-01-21, 05:00
  5. R65 to R70 Upgrade Failure - Patch upgrade failed
    By Felix001 in forum Installing And Upgrading
    Replies: 8
    Last Post: 2010-05-28, 13:43

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •