Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
saitoh
Collaborator
Jump to solution

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.

 

timeout.png

 

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.

image.png

 

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.

image.png

#api status says port443 is open.

api_status.png

FW policy does not block incoming connection.

image.png

Apache access log is like this. (not sure what they mean)

apache.accesslog.png

#fw ctl zdebug +drop shows no drop.

no_drop.png

httpd_ssl_error.log indicates some warnings.

httpd_ssl_errorlog.png

 

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

sliver bullet: casting repero or tossing it into the harbor
0 Kudos
2 Solutions

Accepted Solutions
AkosBakos
Advisor
Advisor

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/

View solution in original post

(1)
G_W_Albrecht
Legend Legend
Legend

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

CCSP - CCSE / CCTE / CTPS / CCME / CCSM Elite / SMB Specialist

View solution in original post

(1)
10 Replies
AkosBakos
Advisor
Advisor

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?

Akos

----------------
\m/_(>_<)_\m/
0 Kudos
(1)
saitoh
Collaborator

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

sliver bullet: casting repero or tossing it into the harbor
0 Kudos
AkosBakos
Advisor
Advisor

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/
(1)
saitoh
Collaborator

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

sliver bullet: casting repero or tossing it into the harbor
0 Kudos
Tal_Paz-Fridman
Employee
Employee

Have you worked with Web SmartConsole before this happened, specifically Logs & Monitor topic?

Try clearing the browser caches to see if it helps.

0 Kudos
saitoh
Collaborator

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

sliver bullet: casting repero or tossing it into the harbor
0 Kudos
G_W_Albrecht
Legend Legend
Legend

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

CCSP - CCSE / CCTE / CTPS / CCME / CCSM Elite / SMB Specialist
(1)
JBhelm
Explorer

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.

0 Kudos
saitoh
Collaborator

Just for your reference, I keep testing this environment, but so far no other workaround has been identified apart from changing ssl-port number.

sliver bullet: casting repero or tossing it into the harbor
JBhelm
Explorer

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.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events