skip to primary navigationskip to content

Access point features

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.


Local SSIDs

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.
  • 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.These networks are only allowed in certain circumstances.
  • 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). These networks are only allowed in certain circumstances.
  • 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 not available for security reasons (e.g. WEP, WPA-TKIP-PSK and WPA-TKIP).

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 due to over subscribing the aceess point.

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.

Remote access points (RAPs)

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.

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 RAP-3 series and 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: 5th July 2018

UIS Service Desk

  Phone padded  01223 332999

UIS Service Status

Phone padded  Service status line: (01223) 463085
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 >  |  Back issues

RSS Feed Latest news

Wireless service maintenance on 13 and 19 November

Nov 12, 2019

The Wireless Service will be subject to interruption between 07:30 and 09:00 on Wednesday 13 and Tuesday 19 November while we carry out essential maintenance.

Windows 7 end-of-life countdown: 2 months to go

Nov 01, 2019

There are only 2 months left until Windows 7 reaches end of life, after which Microsoft will no longer supply security updates and bug fixes for the operating system.

View all news