skip to content
 

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.

Contents

Local SSIDs

University Wireless access points can be configured to offer wireless networks (SSIDs) in addition to, the central service VLANs (eduroam and UniOfCam, UniOfCam-IoT).

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.

For all new requests for locally bridged SSIDs, client devices should support Wireless Protected Access 3 (WPA3).

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, WPA3-AES-SAE, 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.
  • What 802.1Q VLAN ID should be used for the SSID.  Here there are three choices:
    • For VLANs which are to be routed directly by the CUDN, the UIS will allocate a Global VLAN ID.  If this is an existing VLAN, that number will be used for it.  This VLAN will need to be fed from the institution's PoP switch to the required access points.
    • For VLANs which are routed inside (or otherwise private to) institutional networks, the VLAN ID can be selected by the institution but must come from the Local VLAN ID ranges.  The institution will need to create this VLAN on their local network and feed it to the required access points.  There is a potential problem that this number could conflict with some internal numbers used by the wireless system itself — these numbers are gradually being freed up and, until this is complete, if a clash causes a problem, the UIS will advise the institution to select another number.
    • In some cases, the local SSID will be routed by the UIS centrally.  In this case, traffic will be tunnelled over the management network and the VLAN ID will not need to be exposed to the institution, nor will any local configuration be required.

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. Please note that these networks are only allowed in exceptional circumstances.
  • WPA3-AES-SAE ("WPA3 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). These networks are only allowed in certain circumstances and complex keys must be provided (long passwords, 12-15 characters, with a combination of upper and lower-case letters, numbers, and symbols to maintain strong security).
  • WPA3-AES ("WPA3 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 WPA3-AES – The UIS servers proxy authentications to your institutional RADIUS server(s). The local network must be provided by the institution.

Various legacy options are not available for security reasons (e.g. WEP, WPA-TKIP-PSK and WPA-TKIP).

It should be noted that there is a maximum limit of 8 SSIDs per access point radio, including the various UniOfCam and eduroam ESSIDs, to avoid over subscribing the access point and uplink network connection. Access points utilising the downlink enabled ports (e.g. AP-505H) should also have less than 8 SSIDs.

There are several limitations regarding locally-bridged networks:

  • If a public shared key is used, this can only be changed by contacting the Wireless Team  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.

Remote access points (RAPs)

Remote access points are no longer supported by the University Wireless Service

Local switch using wired ports

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 303H (hospitality series) APs), 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. Where necessary VLAN IDs will be allocated by Network Support.

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.

Pass-through ports

Some access points have a pair of ports labelled pass through (e.g. on the AP-303H 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: November 2022

UIS Service Desk

Phone padded  Service status line: (01223 7)67999
Website  Sign up for SMS/email status alerts
Website  Read major IT incident reports

UIS bITe-size bulletin

A regular newsletter aimed at the University's IT community, highlighting service and project news from UIS.

Sign up >

You can read previous editions of bITe-size.

Latest news

Delivering network connectivity for the Cambridge Half Marathon

9 March 2023

Richard Davies from the Granta Backbone Network (GBN) team and Craig Faux from the Networks team, worked together to help deliver network connectivity for the Cambridge Half Marathon that took place this past weekend. The University has been assisting the Council with delivering network connectivity for the Cambridge Half...

Changes to Google Workspace accounts from March

23 February 2023

15 February 2023 We are preparing to delete UIS managed Google Workspace accounts for users that have left the University to maintain system performance and security and reclaim file space ahead of Google introducing file space quotas. When a user leaves the University, their account is flagged as cancelled in Lookup and...

Wireless Service maintenance in March and April 2023

21 February 2023

We’ll be carrying out essential maintenance on the University Wireless Service in March and April 2023 to pave the way for its continued growth. Three phases of work in March and April 1. Tuesday 21 March, 8:00 to 9:00 You might experience interruptions to the UniOfCam-IoT service during the maintenance period. You might...