- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
Good Afternoon - I have another weird one I am hoping someone may have some insight regarding.
We upgraded a group of 1570s from R81.10.08 to R81.10.10 and lost our message banner - revert to .08 and the banner returns.
The syntax used seems to have changed - which is ultimately not an issue - but the banner will not present on .10. It is there when you do a < show configuration > and there if you do a < show message type banner >, and it is present in the /etc/issue file. *But it does not show up. There does not seem to be a way to stop/start the sshd services in Embedded GAIA , similar to GAIA - (we cannot even access /etc/ssh). We tried rebooting, factory defaults/ clean installs, etc - and we tried 3-4 different units. In .08 we just configure from Clish with the set commands and it presents at next login.
Anybody got any tricks?
Example R81.10.08
set message banner msgvalue "Test Banner for R81.10.08" on
set message banner msgvalue "Used Only for Testing 4-24-2025" line on
to
Example R81.10.10
set message type banner msgvalue "Test Banner for R81.10.10" on
set message type banner line msgvalue "Used Only for Testing 4-24-2025" line on
< show configuration >
# Message for the SSH and serial login
set message type "banner" "on" msgvalue "Test Banner for R81.10.10
Used Only for Testing 4-24-2025
"
< show message type banner >
FWSMB1570> show message type banner
msgvalue: Test Banner for R81.10.10
Used Only for Testing 4-24-2025
status: true
Which specific build of R81.10.10 is used , have you tested the more recent R81.10.15 / 17 for the same behavior?
https://sc1.checkpoint.com/documents/SMB_R81.10.X/CLI/EN/Content/Topics/set-message-type-banner.htm
Build 993
Current image name: R81_996002993_10_10
Current image version: 993
Previous image name: <Undefined>
Previous image version: <Undefined>
Default image name: R81_996002993_10_10
Default image version: 993
Bootloader version: 992000129
HW version: 110
Same result - the syntax in your link works - also tabs out exactly the same - we even tried just cut and pasting - that works too. Shows as expected in < show message type banner >, as well as in the < show configuration > = just does not show up at login.
I also tried the syntax for versions below 945 -- We have not tried .17 yet.
I would definitely open TAC case for this.
Andy
Just in case anyone else runs into this problem, i hope not, here is what we came up with - and it is weird.
TAC confirmed the issue on our systems - they said they were unable to recreate the issue in their lab - and that was then end of that.
We ended up testing on another dozen 1555/1570's - straight out of the plastic. Our normal process is to do a clean install prior to deployment - and that is what we did with an initial group of 20. They came with R81.10.10_945 -- we pulled down a new image and did the clean install. You can see in thread that it was R81.10.10_993 - since that is what is presented as GA. No matter what we did/ tried with those 20 the banner would not show up when connected via SSH (*but it would when connected to the console port). We tried upgrades to R81.10.15, R81.10.17, clean installs to R81.10.15/ R81.10.17 - nothing.
But, then we had success when we upgraded from a new one - R81.10.10_945 to .17?! A clean install from R81.10.10_945 to .17 also worked. *But NOTHING worked if _993 was ever present on the gateway?! Even with the clean installs to other latest versions.
Here is the weirdest part - we did a clean install BACK to R81.10.10_945 on the original 20 - and they worked. We tested clean install to .15 and .17, as well as upgrades and roll backs - all worked. If _993 was ever on the gateway it would not work as is and would not work with any upgrades or clean installs moving forward.
And now we are going to hold off on the entire project for a while - see if .17 or something else goes GA.
TAC often is unable to replicate the issue in their lab as they do not use SMB hardware but VMs for testing. Sometimes this makes much difference...
1. So you write:
But NOTHING worked if _993 was ever present on the gateway?! Even with the clean installs to other latest versions.
2. Then:
we did a clean install BACK to R81.10.10_945 on the original 20 - and they worked. We tested clean install to .15 and .17, as well as upgrades and roll backs - all worked.
3. Finally again:
If _993 was ever on the gateway it would not work as is and would not work with any upgrades or clean installs moving forward.
So either 1. and 3. is true or 2. ! As the first batch of twenty has been freed of the issue i would think 2. is the solution, clean firmware install from USBv!
Correct - i went of the rails a little because of all the things we tried!
#2 is correct - but it has to be from a starting point of 945.
Here is the salient part: "...would not work with any upgrades or clean installs moving forward." -- [ Moving Forward] -- we would have thought that doing clean installs to 15 or 17 from 993 would have done trick - apparently not as clean as expected.
What do you mean by clean install ? If you install firmware using USB medium, all that does apply ? Seems very unusual to me...
A clean install to us is done via USB - results in a single image on the gateway. In this case I tried two-three different USBs, re-formatted a couple of times - across multiple, laptops/ workstations and pulled down fresh images a couple of times. I even tried two older versions of Isomorphic
We agree - very unusual!
Clean install by USB like here: https://community.checkpoint.com/t5/SMB-Gateways-Spark/USB-Flash-Firmware-Upgrade/m-p/41746 writes the used firmware version to factory image partition and copies it to a partition later made current. From this the firmware is copied upon start.
Why did you have to try so many USBs, did the install not work as expected ? Isomorphic is not supported on SMBs, btw...
Another important factor is if you did a factory reset ! And if you import a backup after it. When installing a new firmware upgrade, the old configuration is copied to the new one and changed as needed by the new firmware.
Sounds like you put a lot of work into testing that...amazing job. To me, logically, appears to be version related, but hard to be 100% sure.
Andy
Best bet is to involve TAC here
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
9 | |
3 | |
3 | |
1 | |
1 | |
1 |
Tue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Thu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY