Topics Map > University of Chicago > IT Services > Phones & Internet Connections > Wireless
Wireless - FAQs
IEEE 802.1X is a flexible, scalable framework that supports centralized user authentication and network access control. Deploying 802.1X authentication on campus allows us to:
- Strengthen wireless network security by encrypting wireless traffic to the access point
- Relieve IP address exhaustion by assigning private IP addresses to each device on the network
- Position the university for participation in the eduroam (education roaming) program
The benefit most users will see is that they won't be prompted for their CNetID credentials as often. With 802.1X, most devices automatically supply the necessary credentials without prompting the user, even after a period of inactivity, roaming from location to location across campus, or leaving the campus and rejoining the wireless network.
Almost all recent model laptops, netbooks, smartphones have built-in wireless networking. Most desktops and some mobile devices do not include wireless networking--desktops frequently offer wireless as an option and many mobile phones only include cellular connections and not wireless. If your device does have built-in wireless, you will need to purchase an 802.11b or 802.11a/b/g/n network adapter that is 802.1X compatible OR upgrade to a mobile phone/device that includes wireless and is 802.1X compatible as well. 802.1X compatibility is critical since that is the security protocol that facilitates access to the uchicago-secure wireless network. Any 802.11802.11a/b/g/n network adapter network device that fully supports the 802.1X protocol should work. You will also need to configure the 802.1X client (supplicant) that matches your supported operating system version and/or device. Please see our documentation for supported clients/devices for more information:
- Wireless - Manual Configuration For Macintosh 10.5, 10.6 And 10.7
- Wireless - Manual Configuration For Windows XP
- Wireless - Manual Configuration For Windows Vista
- Wireless - Manual Configuration For Windows 7
- Wireless - Manual Configuration For Android
- Wireless - Configuration For IPhone And IPad
In the legacy wireless network, data is not encrypted. Under some circumstances, such as the Firesheep hack for Firefox, data can be stolen as it passes from the device through the wireless access point. With uchicago-secure, data is encrypted between the user device and the access point.
No, speeds should be roughly identical. Once you are fully connected to uchicago-secure, you will be using the same underlying network infrastructure, so the speed remains roughly the same. Depending on how close you are to a wireless access point, and how many people are using that access point (across both uchicago and uchicago-secure), you may get anywhere from 1Mbs to as much as 20 Mbs. It's important to remember that the number of people using a particular access point affects the network's speed. There is a separate wireless infrastructure project under way that will result in faster and more reliable wireless performance.
After moving to a new uchicago-secure location or waking my computer or device from sleep, I appear to be connected but cannot access the network. Why?
Some operating systems and devices do not immediately refresh the connection and there can be a delay of approximately 10-15 seconds for the connection to resume after the device has fully awakened. In some cases, you can speed this along by simply toggling your wireless connection off and then on again. Certain versions of Mac OS X seem to exhibit this behavior more often than others and we continue to look into why this is occurring.
There are some sites or services that I can use with uchicago wireless, but when I switch to uchicago-secure I cannot. Why does this happen?
We have implemented Network Address Translation (NAT) on the uchicago-secure wireless network, which means that your computer or device is assigned a private IP address of the form 10.x.x.x for the purposes of on-campus connectivity. When you connect to off-campus sites, your private 10.x.x.x address is translated to a shared 128.135.x.x address, which permits communication outward to the Internet at large. If you find you cannot access an on-campus service or resource while connected to uchicago-secure, the owner of that service or resource has most likely not been configured to recognize 10.x.x.x addresses as being on campus, or is utilizing local firewall rules to block the connection. Please contact the owner of the service or resource in question to address this oversight.
I have set my computer or device to connect to uchicago-secure. Will I be able to access it from another computer or device while off-campus?
No. Not only will the IP address change due to the use of dynamic address assignment (DHCP), but since uchicago-secure connections utilize Network Address Translation, off-campus devices will not be able to initiate connections to a private 10.x.x.x address.
Since 802.1X generally caches credentials (CNetID and password), it will continue to present those credentials even if someone else is using the device. Best practice if an authenticated device is lost or stolen is to change your CNet password at http://cnet.uchicago.edu. Devices will not immediately be removed from the network but will remain connected until the next time the client authenticates. If there is a need to immediately remove a particular device from the network after having changed the password, please contact IT Services Security at 773-702-2378 (2-CERT) or email@example.com.
In the legacy wireless network, each device that associates with an access point is given a fully routable IPv4 address, even if no user has authenticated. With 802.1X, each device is given an IP address that can be used only on campus. When traffic is sent off-campus, the source address is translated using Network Address Translation (NAT) to an address that can be routed on the Internet. Any response to that traffic is translated back from the Internet-routable address to the private IP address and sent to the user.
As specified in the UChicago Identity by IP address document, any 10.x.x.x address should be recognized as belonging to the university, just like 128.135.x.x addresses. We’ve used 10.135.x.x addresses for several years, but the wireless initiative will include the 10.150.x.x and 10.151.x.x ranges as well. If you are responsible for university resources with access restricted by IP address, please verify that the appropriate IP ranges are allowed. Some common activities that are restricted by IP include remote desktop, file sharing, and secured websites.
Although NAT is new to wireless users at the University of Chicago, it has been commonly used in many areas for a long while. Airports, hotels, Wi-Fi hotspots and even most home networks on a cable modem or DSL usually use NAT to conserve IP space. It is unlikely that any normal wireless activity will be different using NAT. However, some users may have found ways to keep a device on wireless for long periods of time, or using the same IP address continually, and may access that device from off-campus. The off-campus access will no longer be possible under our NAT implementation.
We have no immediate plans to discontinue the captive portal wireless network uchicago, so older devices may continue to use this. To take advantage of the enhanced convenience and security of uchicago-secure, devices, drivers, and operating systems may need to be upgraded and even in some cases replaced entirely.
We have tested methods of enabling 802.1X authentication on remotely managed platforms, including Windows XP, Windows Vista, Windows 7 and Mac OS X. Contact firstname.lastname@example.org for further information.
Note: Do not store your own credentials on machines you are deploying for use by others. At a minimum, prior to deploying a machine, remove any stored user credentials from the device.