- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: Smartview timeout in SmartConsole, GAiA Portal...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Smartview timeout in SmartConsole, GAiA Portal unavailable
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
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
\m/_(>_<)_\m/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @saitoh
Because it is a test and Standalone environment try the following:
- fw unloadlocal
- after this, the SMS is reacable on port443?
- tcpdump -i any host <the IP of teh client host and port 443
- what do you see in the dump?
- Are there only SYN packets?
- what do you see in the dump?
Akos
\m/_(>_<)_\m/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
\m/_(>_<)_\m/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Have you worked with Web SmartConsole before this happened, specifically Logs & Monitor topic?
Try clearing the browser caches to see if it helps.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just for your reference, I keep testing this environment, but so far no other workaround has been identified apart from changing ssl-port number.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
