Captive portal issue

[Rameshwar]

hi

-captive portal is configure for the users 

-on iphone it is working fine 

-for andriod versions i.e it is not poping up the page

-Sign-in to wifi Pop Up is not coming on android 6.0.1, android 5.0, android 4.4.2

-Intermittent connection on mobile applications like facebook messenger and Facebook on random mobile devices despite the "allow all" policy.

-removed chrome browser from the phones and then us browser started poping up the captive portal page 

-once the user is logged in the fb messenger is not working 

-some time it is working and then not connecting 

-on fw it shows that the traffic is allowed and there is no issues 

-please advise what we can check for this issue 

[BPry]

@Rameshwar,

Captive portals get really tricky on mobile, esspecially Chrome. Since the captive portal is effectively re-directing the traffic away from the intended target you run into browsers denying the traffic as it's a threat. In your testing is this specific to HTTP or HTTPS testing or happens regardless? 

[Rameshwar]

@BPry

customer is only complaining about the mentioned andriod phones and mentioning that fb messenger doesnt work , 

is it someting the mentioned version phones of andriod doesnt support in PA 

-what if i enable session cookies to 24 hours will that help ? 

i m thinking they are getting disconnected as per the timer or idle time and then it is not working . please advise 

[BPry]

@Rameshwar,

So I guess a big question would be the following;

1) Does it function correctly at the beginning of the day when they first sign into the captive portal, and eventually stop working; or are they simply never getting the captive portal to come up at all? 

2) Is this a new issue, or is this the start of using captive portal

3) Does this happen on every website or just a few. 

[Rameshwar]

@BPry

1) Does it function correctly at the beginning of the day when they first sign into the captive portal, and eventually stop working; or are they simply never getting the captive portal to come up at all? - now customer complained saying that it was wokring since morning and then it stopped working i.ee messenger 

2) Is this a new issue, or is this the start of using captive portal - this is new implementation .... seems the config issue but not sure what to check to fix this because as per the customer it is working fine with other phones only mentioned andriod phones are giving problem 

3) Does this happen on every website or just a few. - i think everything stops working but i m not sure ...but user is only complaining abut messenger 

[BPry]

@Rameshwar,

When the user is experiancing the issue look at the user mapping associated with the IP address, is there anything actually there for this user. 

[Rameshwar]

@BPry

i think when they face this issue and if i run the command to check and i dont see the user id connected ...when they connect again i can see the user id 

[BPry]

@Rameshwar,

Okay, so that would point to an issue with Android not realizing that the login has expired. The issue with this explanation would be that the firewall should be almost forcing the captive portal on them, so the client should be forced to the captive portal to authenticate again. 

What is your session cookie age-out currently set to; you likely don't want to bring it to a full 24 hours as you would be likely to run into the same issue, making it match a standard workday for the client would likely sufice fine. 

[Rameshwar]

@BPry

thanks , i have actually not checked the cookie age out time on the session , let me check this and extend it to 8 hours as i belive the working time ..

are you suspecting that the idle and timeout time is casuing this issue ? as i believe the idle time calculates the time it didnt receive the traffic and remove the authetication , the timeout is total time allowed for user to connect and re authenticate where in cookie time will surpase both time ...please advise 

[BPry]

@Rameshwar

So the Idle Timer is the time that the user-id is going to stay active. This timer is reset anytime activity is detected by someone logged into the captive portal. If it exceeds your Idle Timer value it's going to remove the mapping. 

The Timer is simply how long it needs to keep the mapping, regardless of the Idle Timer. So even if the user keeps generating traffic to refresh the timer it'll only keep the session active until this value is hit. 

You could easily have a low Timer setting. 

Session cookie if enabled kind of acts as the 'master' setting. The session cookie will keep a session open regardless of Idle Timer or the Timer value. As long as the client is accepting this cookie, and the cookie timeout hasn't been hit, the client will stay authenticated. 

Can you display how you actually have things configured? It could be that the Android Chrome client isn't accepting this cookie and in turn your Idle Timer and Timer values are causing a conflict. 

[Rameshwar]

@BPrythanks for all the suggestion , i have informed the clinet about the senario and it seems they are fine to remove chrome and use other browser as it is working fine with other phones and only few phones has the issue . 

for messenger issue i just changed the user from any to unknown in security policy and then it stopped disconnecting the messenger