Captive Web Portal Timeout Value - Does not work as expected

  • 1
  • Idea
  • Updated 3 years ago
We have configured our Captive Web Portal with a timeout value of 43200 minutes (a month)
However, it's not working.  I learned that the CWP Registration Timeout value only has an effect for as long as the session remains in the roaming cache.

If a user disconnects and does not reconnect for an hour or more, they will be re-presented with the CWP page regardless of the CWP Registration Timeout value.  But I'd like to extend their CWP Registration Timeout across 30 days (to prevent users from having to re-logon/re-accept UAP every single day).  But I guess this fails since the roaming cache entry ages out.

Is this something that can be addressed in future releases?

Photo of Paul Ainslie

Paul Ainslie

  • 25 Posts
  • 3 Reply Likes
  • happy

Posted 4 years ago

  • 1
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
Have you thought of using Private PSKs with thirty day validity periods instead?  The Private PSKs would allow your users to automatically associate when they come within range of the wireless network, as they currently do, and have the following advantages over captive portals:

  • Private PSKs utilise layer two encryption (captive portals have no layer two encryption) so they are more secure than captive portals.  In particular they are less susceptible to man in the middle attacks.
  • Private PSKs do not require interaction with the wireless client's web browser significantly improving client compatibility.
(Edited)
Photo of Paul Ainslie

Paul Ainslie

  • 25 Posts
  • 3 Reply Likes
Thanks! ~ my concern with Private PSK's was the administration of issuing them to each user -- but if they can self register, that would be great!  With a PPSK, how does that work?  Is there a separate SSID which allows them to self register? Then they hop on to the PPSK SSID?
Photo of BJ

BJ, Champ

  • 374 Posts
  • 45 Reply Likes
Simply stated, PPSK is just another authentication method. Rather than a single PSK on that ssid, each registrant would be granted their own PSK, hence private PSK.  
In your instance, they would connect to the ssid, be brought to a cwp, register, be granted a PSK, and go about their business. It's really quite slick.   
Video tutorial for basic configuration...
http://blogs.aerohive.com/blog/networking-luminaries-series/how-to-configure-a-ppsk

Best,
BJ
Photo of Paul Ainslie

Paul Ainslie

  • 25 Posts
  • 3 Reply Likes
My temporary solution was to as follows.  
  • Roaming Cache Update Interval: change from 60 to 75 seconds
  • Roaming Cache Ageout: chg from 60 to 1000
Hence client information will be saved for 20.83 hours (75 x 1000 / 60 / 60).  That's enough time that if they disconnect in the early evening and reconnect the next morning, it will not present them with another login.

Since this is for more of a camp/resort I'm not sure I want to use a PPSK.  Some users will only be there a few days, some more but they could find it confusing.  A CWP is a bit more straightforward.
(Edited)
Photo of Paul Ainslie

Paul Ainslie

  • 25 Posts
  • 3 Reply Likes
Thanks!  I ended up coming to the same conclusion.  The CWP is definitely more user friendly.  I tried the PSK for a bit, but it seemed like everyone needed a personal 'walkthru', so I ditched that.