This section describes features available on University Wireless access points to support extra functionality that some institutions may require, such as additional SSIDs or wired port configuration.
Information about the management support network to connect the access points is described separately.
University Wireless access points can be configured to offer wireless networks (SSIDs) instead of, or in addition to, the central service VLANs (eduroam and UniOfCam). Such networks can provide a mechanism to connect to a local office or guest network.
It should be noted that each additional SSID creates a burden on the performance of the wireless network (affecting all SSIDs, not just the additional ones) and their number and use should be limited. In addition, the UIS strongly advises that services provided to users are not limited to 'internal' local SSIDs which may inconvenience users when they roam outside the physical location of the institution.
If an institution wishes such a service, the following information must be provided:
- What the ESSID (wireless network name) should be. This can technically be anything, but it is recommended that something identifying the institution be chosen (e.g. "Botolph's Guests" rather than just "Guest Network").
- Whether the ESSID should be announced in beacons or "hidden" from wireless network lists in client devices. This is not a security tool as the network can still be found by wireless snooping software or equipment, but is often used to hide a non-public network from being obviously selectable.
- What security should be used on the wireless side of the network (none/open, WPA2-AES-PSK, etc.).
- Which access points the network should be available on (the default is all the ones within an institution; if it is to be selectively available, some access points may need to be reconfigured and restarted). Usually the affected access points should be grouped under a single zone in the Wireless Console.
UIS will allocate a VLAN ID from the CUDN global VLAN number pool and advise the institution of this. This VLAN should be fed tagged to the access points and to wherever it is required within the institutional network (e.g. to an internal firewall or router) — the client traffic will be bridged directly onto the institutional network at the access point where the client is connected; it does not get tunnelled back to the central controller and return to the institutional network via the PoP. UIS does not manage traffic controls or IP addressing on these networks: that is the responsibility of the institution.
For the security options, various choices are available:
- Open – no security. If this choice is used, there will typically need to be some additional security provided internally, to limit or authenticate/authorise access further onto the network. Even if this is done, institutions should be aware that many devices will connect to any open network and attempt to gain internet access, possibly using local IP addresses. Also, traffic over open networks is not encrypted over the air, allowing it to be easily captured.
- WPA2-AES-PSK ("WPA2 Personal") – single, shared key (or passphrase) known by all users. Here a single, shared key is used for all connecting users and traffic is encrypted over the air, such that it cannot easily be captured (although someone with knowledge of the shared key can set up a fake access point to capture traffic).
- WPA2-AES ("WPA2 Enterprise") with Lookup – individual usernames / access passwords. This is essentially the same as eduroam (although the local network must be provided by the institution) but only a subset of users can connect to it (controlled by a Lookup group).
- Federated WPA2-AES – The UCS servers proxy authentications to your institutional RADIUS server(s). The local network must be provided by the institution.
Various legacy options are also available (e.g. WEP, WPA-TKIP-PSK and WPA-TKIP) but are not recommended for security reasons and support being gradually deprecated in Wi-Fi certified equipment.
There is no hard limit on the number of locally-bridged services available to an institution (although the current equipment is limited to a maximum of 8 SSIDs per access point radio, including the UniOfCam and eduroam ESSIDs), but their usage should be kept to a reasonable number.
There are several limitations regarding locally-bridged networks:
- If a public shared key is used, this can only be changed by contacting Network Support. A date and time for a change can be coordinated, but it cannot be changed excessively.
- Access lists cannot be employed on locally-bridged networks, so they are essentially open.
- Usage of locally-bridged networks is not currently reported in the University Wireless Console, although it is logged for diagnostic and abuse purposes.
- The underlying network to which a locally-bridged network connects the client is the responsibility of the institution: they must provide services for IP networking, DHCP, access control and logging, as appropriate.
- The access points have no ability to detect if the client VLAN has been fed correctly to them - if this has not been set up, the client will end up in an isolated network on that access point.
- There is no way to control the VLAN onto which individual clients are based - each ESSID has its own VLAN, on a particular access point.
- Clients cannot be forcibly disconnected or banned from the network.
These limitations may be resolved in future with updates to the system.
RAPs can be attached to almost any network with an internet connection, including being outside the CUDN on a business or domestic broadband connection, or even from another enterprise network. The management network is essentially just the local network, which could be shared with other devices (computers, printers, etc.) and the traffic will pass back to the central controller infrastructure over an insecure network.
RAPs use VPN technology to secure the traffic back to the controllers and should work through most firewalls without any need for specific configuration or permissions. The full requirements for the network they are attached to are:
- The access point must be able to DHCP for its IP address and use a DNS server to find the address of the controller back at UIS.
- The management network can use either public or private addresses, as long as connectivity back to the CUDN is available without needing an explicit proxy or tunnel service. SNAT (Source NAT) is permissible, if necessary.
- Both the management and client traffic will pass through a secured IPSec VPN tunnel, this can require a number of ports, all originated from the access point back to the controllers so should be permitted by a firewall, unless specific blocks are installed:
- The initial connection from the client to the server is made using ISAKMP on UDP port 500. This protocol will be used to authenticate both parties and exchange the security keys, as well as determine if SNAT is in use. It may be necessary to enable IPSec passthrough on a firewall or NAT router to support this.
- If there is no SNAT, the tunnelled traffic will use ESP (Encapsulating Security Payload), IP Protocol 50 - this is an IP protocol separate to UDP and TCP, without port numbers. In addition, ISAKMP will continue to be used to update the security keys and maintain the connection, typically every hour or so.
- If SNAT is detected, the connection will, instead, switch to use NAT-T (IPsec NAT Traversal) on UDP port 4500 as the server port; the client will use whichever port the SNAT has translated its data to, so will be unpredictable. This port is used as a tunnel for the ESP and further ISAKMP traffic, so all communication from this point onwards should use this connection. This protocol is used in preference to ESP as it is difficult to maintain a connections through SNAT with ESP.
If an institution requires access points configured as RAPs, it should state this when they are ordered, although access points can be converted between campus and remote operation remotely, if necessary. However, this must be performed whilst the access point is inside the CUDN and connected to a management network which supports campus mode. Access points configured for campus operation must not be used from outside the CUDN without additional security.
It should be noted that all University Wireless access points are capable of operating as RAPs, including the AP-105/115/225, not just the ones designed specifically for remote operation (e.g. the RAP-3 series).
There are some disadvantages with RAPs due to their more lightweight communication with the central controller infrastructure (because they're expecting a slower WAN uplink with higher latency and less reliable communication). RAPs should typically not be used for APs connected directly to the CUDN.
By default, the wired ports on an access point are configured such that the first one is the uplink to the (untagged) management VLAN and no other ports are usefully active. On access points with multiple ports (e.g. the RAP-3 series and AP-93H), each port can be configured in a manner similar to a switch: VLANs can be presented tagged or untagged on each port and traffic bridged locally between them.
To utilise this functionality, an institution will need to contact Network Support with the desired configuration of each port (which VLAN(s); tagged or untagged), stating which access points this configuration should apply to. The VLANs configured will need to use CUDN global IDs: these will need to be allocated, even if they are only used locally to the institutional network.
Local VLAN bridging is also used to feed the traffic from local SSIDs into the institutional network.
Please note that, as stated above, LLDP-MED is not currently available to advertise a voice VLAN to a phone so this must be manually configured on a handset.
Some access points have a pair of ports labelled pass through (e.g. on the AP-93H there is one on the back and one on the panel at the bottom). This is literally a direct electrical connection between the two ports, allowing a cable to be physically extended through to the other port: the access point does not interfere with the connection either to control VLANs nor supply Power over Ethernet. As such, nothing needs to be (nor can be) configured to use this facility.
Last updated: 7 October 2016