Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
fabiofabio
Collaborator

captive portal disconnections (keep alive)

Hello,
I have already for two weeks opened a TAC with checkpoint assistance to solve a problem in my infrastructure that concerns continuous disconnections of the captive portal. it's a bit long but I'll try to explain to you as we can't get out of this nightmare.
Made the migration from 80.10 - 80.40 the configuration of the captive portal (the web page files) was not reported, which had been modified some time ago because there were these disconnections. This problem has never been completely solved but the changes made have allowed to lower the disconnections (I do not know what changes was). So now, we have the new captive portal page with no special configurations and many disconnections, all the time.
Support offered to raise the "cluster properties> other> user directory> timeout on LDAP request" parameter but it didn't work.
then they proposed to exclude some ip for test from keep-alive in the $ FWDIR / conf / identity_awareness_custom_settings.C file and this worked, the ip excluded from keep-alive no longer have disconnections but this does not seem like a definitive solution, in the meantime ... is it possible to exclude the whole network from keep-alive without repercussions / problems / security threats? if so how do I tell him to exclude everything? have you ever had a similar problem and if so how did you solve it?
(there are about 1300 users connected every day with the captive portal but we are working to remove most of it)

as I show in the screen, the disconnections I am talking about are the "session expirations" which should not be there because, the captive portal should remain active 12 hours (the 11 minutes duration are very frequent)

Cattuhkytedra.PNG


thank you

 

0 Kudos
4 Replies
fabiofabio
Collaborator

UP

0 Kudos
David_Evans
Contributor

Did you get anywhere with this?   I'm seeing the same errors in the smart console logs for some users.

The captive portal page is still open on the client,  but a wireshark capture shows the captive portal keep alive returned a 500 error.
I see the same 500 error in 
CPNacPortal/logs/access_log

I was just searching to see if I could find any info before opening a case.

 

0 Kudos
fabiofabio
Collaborator

I hope you don't have my same disconnection problems ... now I show you how to distinguish the logs as there is nothing written on the internet. the logs that I show in the screenshot are due to the users who open the captive portal page but do not log in, after some time (in my case 11 minutes) the session is terminated and to be able to log in again you have to reload the page.

2.PNG

1.PNG

 

 

the logs that I show below are instead due to a user who already logged in, reloads a page of the captive portal that he had opened before logging in from another tab (it is a bit complicated but playing with the pages of the captive portal and looking at the logs you understand)

3.PNG

 

 

that said, the logs that show you actual disconnections are these (although I'm not totally sure):

4.PNG

 

can anyone confirm what i wrote and maybe do a sk about it? it would be VERY useful for troubleshooting. Because it is not possible to filter only for the latter logs and therefore in very large environments with many logs it is difficult to understand whether or not there are disconnections, also because users may have problems with the first two situations I have described and therefore give feedback not truthful

 

0 Kudos
David_Evans
Contributor

Thankyou for the further explanation.   I'll check on the multiple tabs open to the captive portal.  That might explain some of the randomness.   I have two PC's on the same subnet to the same captive portal.  One user gets disconnected several times a day, the second user never gets disconnected.

But I do see the 500 errors both in the captive portal log and returned in a wireshark capture on the PC.   After the second 500 error, the captive portal / PDP "correctly" pulls their user and networks from all the PEP's.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events