Cross Campus VPN Tunnelling Case Study
The University
of Liverpool
Abstract/Overview
Keywords: wireless, VPN, tunnelling, Bluesocket, authentication, security, visitor.
This case study provides a detailed overview of secure
cross-campus VPN tunnelling between two collaborating institutions, namely the
universities of Liverpool and
Introduction
It is a requirement that each student and staff member is provided with a username and password for use when accessing university IT facilities. Although not technically complex, the overall volume of logon details to issue is a large administrative task, increased further by the additional process of validating the identity of visitors and issuing temporary authentication details accordingly. As well as presenting an additional administrative burden on IT departments, such steps also bring inherent security risks as temporary logon details can often be misplaced, carelessly discarded or exploited. Furthermore, unless deactivated, such accounts could remain active presenting a potential backdoor into a university campus network.
The aim of this project is to help alleviate such potential
problems, and minimise the administrative workload, through the implementation
of an alternative method of authentication whereby participating institutions
can safely grant network access to visitors. The proposed method allows a
visitor to an institution to authenticate a secure network connection against a
local authentication server situated at their home[1]
campus[2].
Pressures to provide enhanced accessibility to computing facilities, combined
with heightened security awareness, suggests that all opportunities to further
enforce and improve upon existing security policies should be openly
considered.
Service Requirements and Constraints
The use of
wireless technologies is necessary to provide a method of connectivity over
which university visitors can establish a connection to their university of
origin. Wireless networking is the preferred method of connectivity as it
provides for flexibility in the locations from which the service can be
implemented and is a rapidly growing, yet well-founded, technology.
Furthermore, in theme of the nature of the project, wireless access is
inherently flexible and always available, requiring little support from the
host university to enable a visitor to establish a connection. Bandwidth
requirements for the implementation of cross campus VPN tunneling are minimal
and are based solely on the number of simultaneous users and their respective
throughput. In comparison to bandwidth both available to, and utilised by, most
institutions the impact will in the majority of circumstances be negligible[3].
The project is subject to, and requires no greater service level requirement,
than that currently implemented for the existing network infrastructure and VPN
server; however successful use of the service will require a working service at
both institutions. Cross campus VPN tunneling requires little additional
support or maintenance as it functions using existing infrastructures and
services for which, in the majority if not all institutions, maintenance and
support will already be available in-house.
Feasibility Study / Site Survey / Cost Comparisons
The cross
campus VPN tunneling project utilised an existing wireless infrastructure and
VPN server at both institutions and therefore there was no requirement to
conduct a site survey or to take additional costs into consideration. However,
if an institution wished to implement the project without having in place the
necessary requirements then extensive feasibility studies, site surveying and
cost comparisons should take place when planning and implementing both a
wireless infrastructure and VPN service.
Although
not implemented specifically for the project, each institution utilised three
key infrastructure components:
- Wireless network
infrastructure;
- VPN Server;
- Bluesocket wireless gateway.
Cross
campus VPN tunneling was initially conceived to allow connections to originate
from a wireless network, generally regarded as being insecure. In practice the
proposed method could be used to allow a VPN tunnel and associated
authentication to take place over any infrastructure presuming a default rule
is in place to allow unauthenticated traffic to reach the target VPN
server. With regards to wireless network access three distinct wireless
standards currently exist, these being 802.11a (54Mbps), 802.11b (11Mbps) and
802.11g (54Mbps), the main difference between the standards being throughput
and range. Any of these wireless standards are suitable; however the
implementation in use at both Liverpool and
If an
institution wishes to participate in cross campus VPN tunneling they will
require a VPN server on campus to which their staff or students can establish a
secure tunnel from the institution that they are visiting[5].
Most institutions have already implemented a VPN server into their network
infrastructure, however if a participating institution does not have a VPN server
they may still participate by permitting visitors’ to their institution access
to the VPN server at their home institution. The
A
Bluesocket wireless gateway is required to follow the guidelines in this case
study. However, the concepts could be applied to wireless networks secured
using different gateways, including a Linux based computer configured as a
NAT/firewall gateway or even a firewall interface onto a demilitarized zone.
The Bluesocket gateway recognises all connections to the wireless network and
denies them access onto the campus network (and beyond onto the Internet) until
successful authentication has taken place. By allowing unregistered users
access to their home VPN server only, it is possible to tunnel directly through
the Bluesocket wireless gateway and authenticate at their home campus
without the need to authenticate against the local gateway.
Although
the implementation of the case study is feasible over a range of different
network infrastructures, there are potential constraints to the implementation
of the case study. The largest constraint is the infrastructure used to supply
a wireless network within a university. The proposed method requires the use of
a gateway to provide firewall and authentication capabilities. This proposed
system would not work for universities that provide authentication within the wireless access points themselves using static username/password
lists or who do not use username/passwords but instead restrict connections
based on MAC address. Additionally if WEP is used to encrypt the wireless
traffic then the WEP encryption key would need to be made available to visitors
and would therefore have a potential impact on the overall security. Obviously
the service also relies on the VPN server at the target university being
available and contactable.
Finally, the performance of the connection will depend on three key
factors, which will be detailed separately below:
- The performance of the wireless
network connection between the client and the wireless access point will
have an impact on the total possible throughput. Although with wireless
speeds operating between 11Mbps and 54Mbps, there are circumstances
whereby if a particularly weak signal is established speeds could be as
low as 1Mbps.
- The performance and load of the
home VPN server is likely to have an impact on the performance of
the service. If a low capacity VPN server is in operation and experiencing
a high load then this will likely have a negative impact on the overall
performance.
- Finally, for completeness, the
network infrastructure transporting traffic between the wireless access
point and the home VPN server will also be a key consideration in
determining performance. However, it is presumed that such an
infrastructure will be unlikely to present any performance considerations
due to the comparatively low throughput being utilised.
Project Planning
The
planning and implementation of the project required collaboration between both
institutions and was broken down into the following aspects:
1)
Realisation
of the need for remote[6]
authentication capabilities.
2)
Investigation
into the feasibility aspects of remote authentication.
3)
Suitability
study undertaken on using existing wireless infrastructures, VPN server
hardware and wireless gateway technologies.
4)
Security,
reliability and performance aspects considered.
5)
Project
scalability and co-ordination assessment.
6)
Implementation
and initial testing.
7)
Real
world testing.
Procurement
N/A
Implementation
The
implementation guide will presume the following:
- A Bluesocket wireless gateway,
running software release V3.0.0.12F or higher, is already physically
installed, configured and operational.
- The reader has knowledge of the
Bluesocket gateway product; including how to access the Bluesocket
administration interface and make configuration changes.
- That a VPN server is installed,
configured and in active service. Configuring and implementing a VPN server
is outside the scope of this case study.
- Any gateway firewalls
controlling access to the Campus network/VPN server will allow connections
from the necessary source locations.
The
Bluesocket wireless gateway acts as a firewall between an insecure
wireless network and a secure campus network. All users connected to the
wireless network are assigned a role by the Bluesocket gateway. Those users who
are connected, but yet to authenticate (and therefore have no access past the
gateway) are assigned an unregistered role. Authenticated users can be assigned
into different roles based on their profile; The University of Liverpool
categorises users into undergraduate, postgraduate or staff roles and can
control access rights accordingly. As visitors to the university will not have
a user account on the local authentication server, it is necessary to allow
them access, through the Bluesocket gateway, to their home VPN server
destination for authentication remotely.
By default
a user is assigned the unregistered role when they have established a
connection to the wireless network and have received an IP address from the
Bluesocket DHCP server (or relayed from a central campus DHCP server) but are
yet to authenticate to receive network access. Whilst in the unregistered role
the Bluesocket gateway restricts access to DNS lookups only (this is necessary
to allow the client to attempt to access a web page which then is redirected to
the Bluesocket login page). For the implementation of cross campus VPN
tunneling, additional access to respective VPN servers at remote campus
locations must be allowed.
- To configure a Bluesocket
wireless gateway the required VPN server destinations must be defined.
- Log into the Bluesocket
administrator interface.
- Select the Destinations
tab and sub option Destinations.
- Add a new Destination with an
appropriate name and the IP address of the associated remote VPN server [See
Appendix A, Image 1].
- Repeat this step for all
required VPN servers.
- Unregistered users should be
granted access to the VPN server destinations.
- Select the Roles tab.
- Edit the unregistered role [See
Appendix A, Image 2].
- Add extra policy entries to
this role allowing any service
in both-directions to the VPN
server destinations [See Appendix A, Image 3].
- Save this once completed.
At this
point the destination VPN servers have been created within the Bluesocket
gateway and access to them has been granted through the unregistered role.
A visitor
to the university should now be able to establish an initial connection to the
local wireless network and then, using their own VPN client, establish a secure
tunnel to their home VPN server with authentication taking place against their
home authentication server. No authentication capability has to be granted
locally once the initial configuration has taken place. Furthermore granting
unregistered access to remote VPN server introduces few security considerations
as VPN servers are, by their nature, generally publicly accessible.
Operational Performance
During the
three months since its implementation the service has operated as expected and
the results have been encouraging.
The aim of
the project was to remove the requirement for obtaining temporary
authentication details when visiting the other institution. Based on this
requirement the project has been a resounding success as authentication can now
take place using the visitors home authentication credentials. The performance
and reliability of the project has been excellent with the use of secure VPN
tunnels not showing any notable impact or degradation on the connectivity
speeds over the wireless network, though clearly they provide additional
security over an insecure wireless medium.
The success
of the project has resulted in its expansion to include London School of
Economics (LSE) who, although not having a VPN server, have successfully
enabled visitors from both Liverpool and
Benefits of Project
The
benefits of cross campus VPN tunneling are significant with regards to a
reduction in administrative tasks and improvements in security. The
effectiveness of the project however is limited by the number of institutions
that implement the scheme. Clearly the greater the number of institutions that
allow cross campus VPN tunneling more useful it will be as a means of remote
authentication.
Lessons Learned
Several
fundamental issues have risen from the project.
- The scalability of the scheme
requires consideration, as each site needs to be specifically configured
to allow default access to all other participating sites. With small
numbers of participants this poses few problems, however with a large
number of sites this could prove unwieldy and would require a central
coordination facility. A proposed approach could be a central list of
participating universities and their VPN server IP address. If a new
institution wishes to participate in the scheme they must submit their
details to the list (to be granted access by all list members) and
likewise they must permit access to all existing entries on the list.
- The use of IP addresses could
be a potential problem if an institution changed the IP address of their
VPN server. This would require each participating institution to update
their configurations accordingly and could be overcome using a fully
qualified domain name. A further improvement on this concept could be made
using a ‘common format’ for domain names that point to a VPN server, for
example vpnserver.liv.ac.uk or vpnserver.ed.ac.uk.
- A separate area for
consideration is the configuration of end user VPN clients[7]
as a user must configure and/or install a VPN client as required for
connection to their home institution. Variations amongst
institutions of VPN server manufacturers and configurations result in a
range of requirements from client software. Knowing such requirements and
associated configuration can create problems for users not based at their
‘home’ university, for example a distance learning student or staff member
working between two institutions. A particular example of this is the use
of split-tunneling to reduce the load on a VPN server by only tunneling
data destined for the target network, all other data destined elsewhere is
directed onto the Internet in the normal manner. This configuration poses
two problems for cross campus VPN tunneling, the first being that it
requires the use of a specific client with a specific configuration before
a session can be established. Secondly, the configuration will only tunnel
data destined for the target network, therefore a user can access data from
their home institution but all other requests to different
destinations are directed over the local wireless network which, as
the user has not locally authenticated, may be blocked.
Summary
To summarise it is clear that the cross campus VPN case study has put forward a useful concept that has been proven to function as planned. Through the use of the scheme security can be greatly increased amongst institutions and likewise the administrative burden on IT departments reduced considerably, especially during the hosting of a large function or seminar. However, the overall success of the deployment of such a scheme would depend largely on the number of participating institutions. Scalability must be considered; as more institutions participate access control filters will become more complex. This can have a detrimental effect on performance. However such performance loss is likely to be insignificant and should not pose any limiting problems.
Stephen Moore
Appendix A
Image 1
Image 2
Image 3