Ben, We also use CloudPath Xpressconnect Wizard to provision our clients. On our Aruba wireless, all DNS queries are destination NATed to our portal DNS server.
We use a custom built portal that redirects DNS queries depending on whether they are permitted to access the server. If access is allowed, DNS queries are redirected to a real DNS server for resolution. If it is not permitted, the client is redirected to our captive portal. We also control what ip ranges are permitted using the wireless firewall capability of Aruba wireless. We also use our open network for registered non-802.1X capable devices We use another captive portal to block access to our web & blackboard servers, redirecting the client to CloudPath for configuration. Our system is complex to set up initially, but it works quite well. I have not seen any Nexus 7 issues so I do not know whether it works here. We do not have a Nexus 7 device for testing. I know we should be able to provide the access for provisioning if needed. A good knowledge of DNS zones is needed to understand our portal server. We have a web-based portal for managing our DNS zones, but it is buggy and needs work. I usually edit the configuration text files manually as needed. Feel free to contact me off-list for more information. Bruce Osborne Network Engineer - Wireless Team IT Network Services (434) 592-4229 LIBERTY UNIVERSITY Training Champions for Christ since 1971 From: Higgins, Benjamin John [mailto:[email protected]] Sent: Monday, May 5, 2014 3:32 PM Subject: Proxy for Wi-Fi Provisioning Phones and Tablets Good Day Everyone: We are currently using CloudPath as a Wi-Fi___33 setup point for all wireless devices on campus. This solutions works rather well for all devices which are "pre-activated". We have an unencrypted SSID, most DNS queries redirect to the CloudPath server for setup. Some URLs, such as ocsp.thawte.com, point to a proxy setup on Apache. 99% of the time, as is well. However, when a student orders a new Nexus 7 (for example) they must activate the device with Google. This must be done prior to being able to install the CloudPath app which in turn installs all the EAP-TLS certificates needed to work on our wireless network. While my example is Nexus 7, we know that we have similar problems with Verizon iPhones as well. In practice, when the Nexus 7 is turned on - it displays the Welcome Screen and asks for which Wi-Fi___33 SSID to use. It then happily attempts to go off to the Internet and do ... whatever. In our case, we end up redirecting clients3.google.com to the CloudPath site - and the Nexus is intelligent enough to realize you have to login to continue. *BUT* our environment requires walking through CloudPath to setup EAP-TLS and install the associated certificates ... which can't be installed because the device is in setup mode ... because the device can't get to the Internet ... because it's not setup for our environment ... because it's in setup mode because... *continue recursive query* How have other institutions dealt with this issue? Do you purposely drop the new provisioning use case? Are we unique with a captive portal and configuration site? We are looking at additional proxy apache sites in our configuration - and have had limited success ... until we stare TLS/SSL encrypted web URLs in the face. Any thoughts (no matter how wacky) are welcome! -- Benjamin J. Higgins ('97), JNCIA-Junos | [email protected]<mailto:[email protected]> Network Engineer | Office 508.831.4860 Worcester Polytechnic Institute | Cell 508.713.1739 ********** 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/.
