- Products
- Learn
- Local User Groups
- Partners
- More
Introduction to Lakera:
Securing the AI Frontier!
Quantum Spark Management Unleashed!
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!
Hi all!
I am creating test environment for R81.20 standalone.
After conducting some test associated with how CP treats certificates, I noticed Smartview went timeout at the screen like the attachment.
Google told me that this happens when the device has no access towards SMS at port443.
A connection to GAiA Portal goes timeout as well, so I can confirm this.
Therefore my assumption here is problem will get resolved if I retrieve port443 availability.
However I had no idea why CP will not respond to https access.
Chrome says it is ERR_TIMED_OUT.
I took a look at processes as far as my little knowledge reaches,
only to find it out that I need some help.
ps command shows there are httpd process alive I think.
#api status says port443 is open.
FW policy does not block incoming connection.
Apache access log is like this. (not sure what they mean)
#fw ctl zdebug +drop shows no drop.
httpd_ssl_error.log indicates some warnings.
I have a few month experience of CP and linux system.
I do not know what else to check... 😞
Any comments/suggestions are more than welcome!
Saitoh
Hi @saitoh
From a little info, we can give only tips.
The access was worked before it think. What is came into my mind, is that, you need to change the port of the GAIA portal, because the 443 is for SSL VPN.
If you change it in CLISH.
Here is a good explanation:
https://community.checkpoint.com/t5/Management/Change-GAIA-SSL-Port-R80-20/td-p/25056
Akos
I would like to share with you that R&D knows about this issue and will resolve it in the upcoming R81.20 JHF Take
To get a HF before the new Jumbo is released, ask TAC for ReportingServer_HOTFIX_R81_20_JUMBO_HF_590_MAIN_GA_FULL.tar
Hi @saitoh
Because it is a test and Standalone environment try the following:
Akos
Dear @AkosBakos ,
Thanks for your reply!
I forgot to mention fw unloadlocal made no difference sadly.
tcpdump produces some lines below. I am now reading them to find out how negotiation goes.
----------
tcpm dump -i any host * "10.31.10.2 and port 443* ` + " -v
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
17:09:13.536651 IP (tos 0x0, ttl 128, id 13806, offset 0, flags [DF], proto TCP (6), length 52)
10.31.10.2.63149 > 10.31.10.1.https: Flags [S], cksum 0xa3d6 (correct), seq 1719862977, win 8192, options [mss 8960,nop,wscale 8,nop,nop,sackOK], length 0
17:09:13.536820 IP (tos 0x0, ttl 128, id 13807, offset 0, flags [DF], proto TCP (6), length 52)
10.31.10.2.63150 > 10.31.10.1.https: Flags [S], cksum 0x9255 (correct), seq 2859521107, win 8192, options [mss 8960,nop,wscale 8,nop,nop,sackOK], length 0
17:09:13.537155 IP (tos 0x0, ttl 255, id 32705, offset 0, flags [DF], proto TCP (6), length 52)
10.31.10.1.https > 10.31.10.2.63149: Flags [S.], cksum 0xa584 (correct), seq 2973338197, ack 1719862978, win 65535, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
17:09:13.537325 IP (tos 0x0, ttl 128, id 13808, offset 0, flags [DF], proto TCP (6), length 40)
10.31.10.2.63149 > 10.31.10.1.https: Flags [.], cksum 0xde50 (correct), ack 1, win 2053, length 0
17:09:13.537361 IP (tos 0x0, ttl 255, id 53789, offset 0, flags [DF], proto TCP (6), length 52)
10.31.10.1.https > 10.31.10.2.63150: Flags [S.], cksum 0xbf5f (correct), seq 3110229712, ack 2859521108, win 65535, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
17:09:13.537440 IP (tos 0x0, ttl 255, id 63971, offset 0, flags [DF], proto TCP (6), length 40)
10.31.10.1.https > 10.31.10.2.63149: Flags [.], cksum 0xd655 (correct), ack 1, win 4096, length 0
17:09:13.537474 IP (tos 0x0, ttl 128, id 13809, offset 0, flags [DF], proto TCP (6), length 40)
10.31.10.2.63150 > 10.31.10.1.https: Flags [.], cksum 0xf82b (correct), ack 1, win 2053, length 0
17:09:13.537549 IP (tos 0x0, ttl 255, id 48412, offset 0, flags [DF], proto TCP (6), length 40)
10.31.10.1.https > 10.31.10.2.63150: Flags [.], cksum 0xf030 (correct), ack 1, win 4096, length 0
17:09:13.538479 IP (tos 0x0, ttl 128, id 13810, offset 0, flags [DF], proto TCP (6), length 1500)
10.31.10.2.63150 > 10.31.10.1.https: Flags [.], cksum 0x7b59 (correct), seq 1:1461, ack 1, win 2053, length 1460
17:09:13.538499 IP (tos 0x0, ttl 128, id 13811, offset 0, flags [DF], proto TCP (6), length 281)
10.31.10.2.63150 > 10.31.10.1.https: Flags [P.], cksum 0xa10c (correct), seq 1461:1702, ack 1, win 2053, length 241
17:09:13.538585 IP (tos 0x0, ttl 255, id 35683, offset 0, flags [DF], proto TCP (6), length 40)
10.31.10.1.https > 10.31.10.2.63150: Flags [.], cksum 0xe98b (correct), ack 1702, win 4096, length 0
17:09:13.538958 IP (tos 0x0, ttl 128, id 13812, offset 0, flags [DF], proto TCP (6), length 1500)
10.31.10.2.63149 > 10.31.10.1.https: Flags [.], cksum 0x1bf2 (correct), seq 1:1461, ack 1, win 2053, length 1460
17:09:13.538974 IP (tos 0x0, ttl 128, id 13813, offset 0, flags [DF], proto TCP (6), length 281)
10.31.10.2.63149 > 10.31.10.1.https: Flags [P.], cksum 0x15e6 (correct), seq 1461:1702, ack 1, win 2053, length 241
17:09:13.539079 IP (tos 0x0, ttl 255, id 64834, offset 0, flags [DF], proto TCP (6), length 40)
10.31.10.1.https > 10.31.10.2.63149: Flags [.], cksum 0xcfb0 (correct), ack 1702, win 4096, length 0
17:09:43.538797 IP (tos 0x0, ttl 128, id 13854, offset 0, flags [DF], proto TCP (6), length 40)
10.31.10.2.63150 > 10.31.10.1.https: Flags [F.], cksum 0xf185 (correct), seq 1702, ack 1, win 2053, length 0
17:09:43.539003 IP (tos 0x0, ttl 255, id 21090, offset 0, flags [DF], proto TCP (6), length 40)
10.31.10.1.https > 10.31.10.2.63150: Flags [F.], cksum 0xe989 (correct), seq 1, ack 1703, win 4096, length 0
17:09:43.539113 IP (tos 0x0, ttl 128, id 13855, offset 0, flags [DF], proto TCP (6), length 40)
10.31.10.2.63150 > 10.31.10.1.https: Flags [.], cksum 0xf184 (correct), ack 2, win 2053, length 0
17:09:43.543726 IP (tos 0x0, ttl 128, id 13857, offset 0, flags [DF], proto TCP (6), length 40)
10.31.10.2.63149 > 10.31.10.1.https: Flags [F.], cksum 0xd7aa (correct), seq 1702, ack 1, win 2053, length 0
17:09:43.543854 IP (tos 0x0, ttl 255, id 24790, offset 0, flags [DF], proto TCP (6), length 40)
10.31.10.1.https > 10.31.10.2.63149: Flags [F.], cksum 0xcfae (correct), seq 1, ack 1703, win 4096, length 0
17:09:43.543953 IP (tos 0x0, ttl 128, id 13859, offset 0, flags [DF], proto TCP (6), length 40)
10.31.10.2.63149 > 10.31.10.1.https: Flags [.], cksum 0xd7a9 (correct), ack 2, win 2053, length 0
----------
Saitoh
Hi @saitoh
From a little info, we can give only tips.
The access was worked before it think. What is came into my mind, is that, you need to change the port of the GAIA portal, because the 443 is for SSL VPN.
If you change it in CLISH.
Here is a good explanation:
https://community.checkpoint.com/t5/Management/Change-GAIA-SSL-Port-R80-20/td-p/25056
Akos
Dear @AkosBakos ,
To my surprise, changing ssl-port worked and availability of GAiA Portal retrieved!
I have done no changes associated with ssl-port, which is confirmed by the points below.
>#api status
the capture is attached on the previous post.
>Platform Portal
I checked it before committing ssl-port change.
It has not port specification.
@G_W_Albrecht thankfully tells me here that this issue has been already under investigation.
Still no idea how this is triggered, but for now I take it for just an error, not misconfiguration or something...
Thanks community contributers!
Saitoh
Have you worked with Web SmartConsole before this happened, specifically Logs & Monitor topic?
Try clearing the browser caches to see if it helps.
Dear @Tal_Paz-Fridman,
I did not touch Web SmartConsole before/after this error happens.
I tried to see if it works just now, only to find out it did not show up by same error(ERR_TIMED_OUT).
Saitoh
I would like to share with you that R&D knows about this issue and will resolve it in the upcoming R81.20 JHF Take
To get a HF before the new Jumbo is released, ask TAC for ReportingServer_HOTFIX_R81_20_JUMBO_HF_590_MAIN_GA_FULL.tar
Other than waiting for a new JHF, is there a workaround i can do to make this work for now? Im in a scenario right now where rolling back is not possible short-term.
Just for your reference, I keep testing this environment, but so far no other workaround has been identified apart from changing ssl-port number.
Ooh that was also a confirmed working workaround, im so sorry, went right over my head. Ill try that as a temporary workaround for now. Thanks so much.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
24 | |
15 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 | |
2 | |
2 |
Tue 30 Sep 2025 @ 08:00 AM (EDT)
Tips and Tricks 2025 #13: Strategic Cyber Assessments: How to Strengthen Your Security PostureTue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFTue 30 Sep 2025 @ 08:00 AM (EDT)
Tips and Tricks 2025 #13: Strategic Cyber Assessments: How to Strengthen Your Security PostureThu 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