- Products
- Learn
- Local User Groups
- Partners
-
More
Celebrate the New Year
With CheckMates!
Value of Security
Vendor Self-Awareness
Join Us for CPX 360
23-24 February 2021
Important certificate update to CloudGuard Controller, CME,
and Azure HA Security Gateways
How to Remediate Endpoint & VPN
Issues (in versions E81.10 or earlier)
Mobile Security
Buyer's Guide Out Now
Important! R80 and R80.10
End Of Support around the corner (May 2021)
Has anyone encountered this before: during FTW, after management interface is defined with the same IP as the WebUI is using, the buttons are grayed-out and the process cannot progress further:
The image is Check_Point_R77.30_Install_and_Upgrade_T5.Gaia.iso and I have tried it with multiple browsers (Chrome required a one-liner to work, but IE was working from the start).
Gateway or Management?
If management, it might be this: Cannot Connect with SmartConsole to R77.30 or Earlier Management
It was not yet defined: I am in the process of running FTW and did not get to specify what it'll be yet.
The sequence goes:
...and we're stuck.
You most probably tried it, but have you got the smae result after page refresh or clear cache and page refresh?
Tried emptying the cache, refresh, different browsers and rebooted the VM.
Same results. Cannot exclude possibility of corrupted installation, unless there is some other gremlin at work.
if you make changes to the interface page, what interface are you connected to when you start the FTW?
As you are stating that "after management interface is defined with the same IP as the WebUI is using"
To that rings a bell that says you were connected to another interface? You normally do not change the interface you are connected to during the running of the FTW.
You set the interface upfront through CLI if you want and then connect to that interface and run the FTW.
Nope: same interface. That’s what’s puzzling. Nothing changes, simply clicking through the FTW stop responding after this page.
Did you backdate the system as indicated just to makes sure the Certificate issue is not bothering you here?
Hugo,
Haven't tried the backdating yet, as the epoch issue manifests itself later in the process, when we try to connect to the management via SmartDashboard.
I am curious to know if the Check_Point_R77.30_Install_and_Upgrade_T5 already contains the fixes from JHF 143 that addressing it.
As I am going through the FTW, the self-signed cert is a valid one:
And since I have not yet defined this system as a management server, (planing to do that later in the setup), the internal CA is not yet in play.
I've reinstalled the VM and the issue is no longer present. Must've been a corrupt installation.
Good to hear it doesn't repeat after reinstall. I was thinking about corrupted installation package at all. If are checksums ok.
I had similar issue, finally sorted by recreating VM with the spec mentioned below. Main reason for this issue I found was due to ram and hard disk allocation on VM. Once I allocated 25gb hard disk space and 1.6 gb of ram the issue was fixed.
Thank you Raaj. I'll keep it in mind, but I typically provision HDD space, RAM and CPU fairly generously for VMs.
Pretty sure even 25gb of disk and 1.6gb of RAM are below the minimum requirements for R77.x.
At the very least you should allocate the amounts specified in the release notes.
The OVF for R77.30 is packed with a 10GB disc. you cannot really run standalone on it with more than 1 GB of log data. Upgrade is impossible and even running a jumbo can be challenging.
Maarten,
The OVF is explicitly provisioned for Gateways.
The management VM was always supposed to be deployed from ISO.
About CheckMates
Learn Check Point
Advanced Learning
WELCOME TO THE FUTURE OF CYBER SECURITY