We have the same problem using Cloudpath and Cisco WLC's with a PacketFence 
Guest Captive Portal.  I am looking at a different approach though because like 
Ryan said - it will be a constant battle updating the ever-changing ACL's.  
This is a battle we will lose.
 
I'm trying to see if I can have PacketFence change the Pre-auth ACL to the 
Post-auth ACL just before the page where the user is presented with the play 
store download.  Essentially, the idea is that once they realize they can't get 
out - they start using the onboarding process, and then at the last page when 
they click "continue" it takes them to the app download, but also the 
"continue" button initiates the change from Pre-auth to Post-auth ACL allowing 
them to get to everything.

So at that point yes a user could get out, but my bet is that they are not 
interested in trying to get out - they are just trying to complete the 
onboarding process now.  If it works on the first try they'll stick with it - 
if not, they'll go for the guest network anyway before ever submitting a ticket 
and letting us know we have to add yet another URL to the Pre-auth ACL .  Also, 
since we already recorded their username, voucher or phone number in the 
onboarding process, if they do get out at least they are not anonymous.  We 
know a few things about them and can contact them.  Plus they'd have to go 
through the same annoying process every 24 hours if they really wanted to abuse 
the system.

In short, I'd rather have a process that works every time for users that follow 
it than have one that fails often so users choose not to follow it.


Curtis Larsen
University of Utah IT/CIS
Sr. Network Engineer

________________________________________
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Bruce Curtis 
[bruce.cur...@ndsu.edu]
Sent: Saturday, May 30, 2015 6:28 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] google play ACL

  We have the same problem.  I plan to give up on trying to keep track of the 
various things that need to be allowed.

  As part of the process to have a cert generated and downloaded our users have 
to log into a web page.  I plan to only allow access to the Internet after they 
have logged in to the web page.  To discourage using this method to access the 
Internet rather than configuring WPA2 on their device we will have a short 
timeout so that they would have to enter their ID and password every X minutes. 
 In addition the device we are using to redirect to our web page makes it 
fairly easy to block access to Facebook and Twitter etc.

On May 29, 2015, at 9:25 AM, Jacob Bennefield <jacob.bennefi...@lamar.edu> 
wrote:

> We have been working with Ruckus and Cloudpath on this issue as well.  These 
> are the web addresses we allow to make google play and a few other things 
> accessible.  You basically have to open up everything to google but google.com
>
>                 2              ocsp.digicert.com            EditClone
>                 3              crl3.digicert.com               EditClone
>                 4              crl4.digicert.com               EditClone
>                 5              *.play.google.com           EditClone
>                 6              *.ssl.gstatic.com               EditClone
>                 7              *.android.clients.google.com     EditClone
>                 8              *.googleusercontent.com           EditClone
>                 9              *.ggpht.com      EditClone
>                 10           *.geotrust.com EditClone
>                 11           *.appengine.google.com             EditClone
>                 12           *.settings.crashlytics.com            EditClone
>                 13           *.googleapis.com            EditClone
>                 14           *.cloud.google.com        EditClone
>                 15           *.gvt1.com         EditClone
>                 16           *.android.com  EditClone
>                 17           passwordreset.lamar.edu            EditClone
>                 18           *.amazon.com  EditClone
>
>
>
> Jacob Bennefield, BBA
> Manager of Network Services
> Lamar University
> jacob.bennefi...@lamar.edu
> Phone: 409-880-7997
>
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Turner, Ryan H
> Sent: Friday, May 29, 2015 9:01 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: [WIRELESS-LAN] google play ACL
>
> Hello all,
>
> I’ve asked this question in the past, got some answers, attempted to 
> implement some solutions, and have ultimately been disappointed with the 
> results…
>
> Our problem:  We have a limited access onboarding SSID.  Currently, users 
> must download the cloudpath agent directly from OUR server, requiring them to 
> configure their devices to allow non google market place applications.  I am 
> attempting to streamline the onboarding process by allowing access to google 
> play directly to download the onboarding application, but am failing 
> miserably…  I have put up the white flag and opened up most of google, but 
> now I am finding that through a combination of cache servers, and Samsung 
> devices that appear to query for their own app store first, my results work 
> only half the time.
>
> Has anyone else figured out a way to solve this madness?  We are not going to 
> open up the SSID to everything, because people would just use it and not the 
> proper wireless.
>
>
> Ryan H Turner
> Senior Network Engineer
> The University of North Carolina at Chapel Hill
> CB 1150 Chapel Hill, NC 27599
> +1 919 445 0113 Office
> +1 919 274 7926 Mobile
>
> ********** Participation and subscription information for this EDUCAUSE 
> Constituent Group discussion list can be found 
> athttp://www.educause.edu/groups/.
>
>
> CONFIDENTIALITY: Any information contained in this e-mail
> (including attachments) is the property of The State of Texas and
> unauthorized disclosure or use is prohibited. Sending, receiving or
> forwarding of confidential, proprietary and privileged information is
> prohibited under Lamar Policy. If you received this e-mail in error,
> please notify the sender and delete this e-mail from your system.
>
> ********** Participation and subscription information for this EDUCAUSE 
> Constituent Group discussion list can be found at 
> http://www.educause.edu/groups/.

---
Bruce Curtis                         bruce.cur...@ndsu.edu
Certified NetAnalyst II                701-231-8527
North Dakota State University

**********
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

**********
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

Reply via email to