Connecting to University Research Clusters: A Case Study in Navigating VPN Challenges and Open-Source Solutions

The increasingly complex landscape of academic IT infrastructure, particularly concerning secure remote access to vital research computing resources, was highlighted by a recent experience shared by a researcher utilizing the University of Surrey’s Eureka2 high-performance computing (HPC) cluster. The detailed account, originally published on pacha.dev, chronicles the challenges encountered when attempting to establish a VPN connection from a personal Arch-based Linux distribution, Omarchy, to the university’s secure network, ultimately demonstrating the utility of open-source software in overcoming proprietary system hurdles.

The researcher’s objective was to access Eureka2, a significant computing asset for academic research at Surrey, using their personal laptop. However, the institution’s prescribed method for off-campus access, which involved downloading Global Protect VPN client software from a now-retired "Surrey App Store," presented an immediate obstacle. This situation underscores a common dilemma faced by researchers and students alike: the reliance on legacy or unsupported software distribution channels within academic institutions.

The Initial Hurdle: Obsolete Software Distribution

The official guidance from the University of Surrey, specifically a PDF document titled "Working off campus with GlobalProtect," directed users to procure the necessary VPN client from a centralized app store. The retirement of this "Surrey App Store" meant that the primary, officially sanctioned method for acquiring the Global Protect client was no longer available. This left users, particularly those employing operating systems not typically supported by commercial VPN clients, in a precarious position.

The researcher, operating on Omarchy, a Linux distribution known for its efficiency and Arch Linux foundation, found themselves needing an alternative solution. Many universities, including Surrey, have mandated the use of Microsoft Authenticator for multi-factor authentication (MFA) when logging into sensitive systems like VPNs. This requirement adds another layer of complexity, as the VPN client must not only establish a secure tunnel but also seamlessly integrate with the MFA process.

Embracing Open Source: The OpenConnect Solution

In response to the unavailability of the official client, the researcher turned to OpenConnect, a robust open-source software project designed to establish VPN connections. OpenConnect is known for its versatility and its ability to interface with various VPN protocols, including the GlobalProtect VPN (GP) protocol, which is utilized by many institutions.

The installation of OpenConnect on an Arch-based system is typically straightforward, facilitated by package managers. The command sudo yay -S openconnect reflects this ease of installation within the Arch ecosystem, leveraging the yay AUR (Arch User Repository) helper. This adoption of open-source alternatives by individuals within academic settings is a growing trend, often driven by the need for greater control, compatibility with non-standard operating systems, and a commitment to free and open-source software principles.

Navigating Authentication and Configuration

The subsequent challenge involved configuring OpenConnect to authenticate successfully with the University of Surrey’s VPN infrastructure, which relies on Microsoft Authenticator for MFA. This required a two-pronged approach: ensuring the underlying Microsoft account settings were correctly configured and then formulating the correct command-line arguments for OpenConnect.

The researcher first adjusted their Microsoft security information settings via the provided link, https://mysignins.microsoft.com/security-info. The critical step here was verifying that the default sign-in method was set to "Microsoft Authenticator – notification." This ensures that when a connection attempt is made, the system prompts for an approval via the Microsoft Authenticator app on the user’s mobile device.

The command executed to initiate the VPN connection was:
sudo openconnect --protocol=gp --usergroup=gateway vpn.surrey.ac.uk

This command specifies the Global Protect protocol (--protocol=gp) and the user group (--usergroup=gateway), which are essential parameters for establishing a connection to the university’s VPN gateway at vpn.surrey.ac.uk.

The Nuances of Username and Password Authentication

A significant hurdle, as detailed in the original account, was the precise format of the username and the authentication process itself. The researcher discovered that simply using their email address or a shortened username was insufficient. Instead, the full university username, appended with @surrey.ac.uk, was required. This is a common point of confusion in university IT systems, where internal usernames may differ from email aliases.

Furthermore, the password authentication involved a combination that is often a source of frustration for users: the password for a specific university service, in this case, "Surrey Learn," rather than the general email password, followed by a time-based one-time password (TOTP) generated by the Microsoft Authenticator app. This distinction between different service passwords within a single institution can lead to errors and prolonged troubleshooting.

After several attempts, the correct authentication sequence enabled the establishment of the ESP (Encapsulating Security Payload) session, indicated by the successful output:
ESP session established with server
ESP tunnel connected; exiting HTTPS mainloop.

Accessing the Eureka2 HPC Cluster

With the VPN connection successfully established, the researcher could then proceed to connect to the Eureka2 HPC cluster. This was achieved via SSH (Secure Shell) to the cluster’s login node:
ssh [email protected]

The successful SSH connection yielded the expected welcome message from the Eureka2 cluster:
+++++++++++++++++++++++++++++++++++++++++
Welcome to Surrey's Eureka2 HPC Cluster
Based on Rocky 8
+++++++++++++++++++++++++++++++++++++++++

Documentation for HPC users is at below site:
https://docs.pages.surrey.ac.uk/research_computing/

Broader Implications and Analysis

This incident, while specific to the University of Surrey, highlights several critical issues relevant to academic IT and research computing globally:

1. The Challenge of Software Support for Diverse Operating Systems: Academic institutions often develop IT policies and deploy software solutions that are primarily designed for mainstream operating systems like Windows and macOS. Researchers and students using Linux distributions, or even older versions of supported operating systems, can face significant barriers to accessing essential resources. The reliance on proprietary clients can exacerbate this problem, as they are not always developed with cross-platform compatibility or open-source alternatives in mind.

2. The Evolution of VPN and MFA Technologies: The increasing adoption of robust VPN protocols and multi-factor authentication methods is crucial for enhancing security. However, the implementation of these technologies, particularly the integration with diverse client environments, requires careful planning and ongoing support. The University of Surrey’s shift away from a centralized app store for software distribution, while potentially streamlining other aspects of IT management, created a gap for users relying on non-standard configurations.

3. The Power of Open-Source Solutions: The researcher’s successful use of OpenConnect underscores the vital role of open-source software in providing flexible and adaptable solutions. Projects like OpenConnect not only offer viable alternatives to proprietary software but also foster a collaborative environment where technical challenges can be overcome through community effort. This is particularly important in academic settings where budget constraints can limit the procurement of commercial software licenses for every possible use case.

4. The Importance of Clear and Accessible Documentation: The initial reliance on an official guide that pointed to a retired service highlights a common issue with IT documentation in large organizations. As systems evolve, documentation must be consistently updated and reflect current best practices and available resources. The researcher’s own effort to document their solution serves as a testament to the need for peer-to-peer knowledge sharing when official channels prove insufficient.

5. The Researcher’s Perspective: Time and Resource Investment: The researcher explicitly stated that they spent "over half an hour figuring out the steps by reading different sources." This represents a significant investment of time that could have been dedicated to research activities. For individuals without the technical expertise or inclination to troubleshoot such issues, this could lead to a complete inability to access critical research infrastructure, thereby impacting their academic progress.

Future Considerations for Academic Institutions

To mitigate similar challenges, academic institutions might consider the following:

• Broadening Software Distribution Channels: Exploring alternative methods for distributing essential software that are not reliant on single points of failure, such as retired app stores.
• Prioritizing Cross-Platform Compatibility: When selecting VPN clients and other essential software, giving strong consideration to solutions that offer robust support for Linux and other less common operating systems.
• Maintaining Comprehensive and Up-to-Date Documentation: Regularly reviewing and updating all IT documentation to reflect current software versions, access methods, and troubleshooting advice. This includes providing clear instructions for alternative access methods, such as open-source clients.
• Leveraging Open-Source Communities: Engaging with and potentially supporting open-source projects that are critical for academic use, fostering a mutually beneficial relationship.
• Providing Dedicated Support for Diverse User Needs: Recognizing that the academic community comprises users with a wide range of technical backgrounds and operating systems, and offering tailored support where possible.

The experience of connecting to the Eureka2 HPC cluster serves as a valuable case study, illustrating the persistent need for adaptability and the power of community-driven solutions in navigating the complex technological landscape of modern research environments. It highlights that while institutions strive for secure and efficient access, the reality for individual researchers often involves a proactive engagement with available tools, including the robust and ever-evolving world of open-source software.