Replacing VPN Light: solutions and approaches

Allowing unmanaged and unknown devices to connect to KI’s internal network and IT solutions entails extremely high risks to our IT environments - risks that are not acceptable when secure alternatives are provided by the IT Office. On this page you will find solutions and ways of working adapted to different needs and technical prerequisites.

Why is VPN Light being phased out? Security and legal background

VPN Light, which provides unmanaged computers with access to KI’s internal IT resources containing sensitive information, significantly increases the risk of intrusion, malware propagation, unauthorised access and data exfiltration. This is because the security posture of client devices (such as patching status, EDR/antivirus protection, configuration and identity protection) cannot be verified or enforced.

This type of implicit trust makes it difficult to uphold the principles of least necessary privilege, strong authentication and network segmentation. It also complicates traceability and incident management when devices lack centralised logging and control.

These shortcomings conflict with the increased requirements introduced through NIS2 and Swedish cybersecurity legislation, which mandate the protection of networks and information systems and the implementation of appropriate technical and organisational security measures to safeguard information assets.

Furthermore, MSBFS 2020:7 (and corresponding requirements in established security frameworks) emphasises the need for access governance and protection against unauthorised dissemination. For this reason, access to internal resources containing sensitive information should only be permitted from managed and controlled devices, using secure and verifiable access models.

Do you need VPN to access what you are working on?

The IT Office (ITA) has actively worked to reduce the number of systems and services that require VPN when working remotely. Today, the vast majority are accessible simply by signing in with your KI ID.

At the bottom of the KI‑VPN page you will find an up‑to‑date list showing what does and does not require VPN access.

If you do not need VPN for your current task, you can simply choose not to connect.

Linux users

KI and ITA do not support Linux as a primary work computer. The centrally managed Windows or Mac client, Karyon, includes all required security functions to protect KI’s information and IT solutions.

ITA has been tasked by KI’s University Board and senior management with managing shared and central IT services. If you choose to operate outside this framework and use a personal Linux machine as your primary workstation, you will in practice not be able to use central services to the same extent as when using a Karyon client.

The recommendation is therefore to transition to a Karyon client for day‑to‑day work. Many of the use cases currently handled on Linux can today also be fulfilled on a Mac.

Technical options for Linux on a Karyon client

Windows 11: use WSL for terminal‑based Linux environments.

You can also use VMware to run a "full GUI Linux virtual machine" on Windows or Mac.

Use an IAAS Linux server

Switch to a Karyon client and order an IaaS/IaaS+ Linux server through ITA, hosted in KI’s data centre. You then work against the server via SSH. The server is always available and can be accessed both on and off campus, for example via SSH or KI’s VPN service.

Hardware‑close development or Linux‑based instruments

  • Switch to a Karyon client and procure a headless computer (desktop, NUC or similar) and install Linux on it.
  • Connect your hardware or instrument to the dedicated Linux machine and connect it to the lab network. Request the lab network connection by creating a case in KI Self Service and providing the computer’s MAC address.
  • Administer the computer via SSH, VNC or similar from your Karyon client. You can also reach the lab computer when off campus by connecting your Karyon client through KI’s VPN service.

Administration of servers, file servers and large data volumes

Administering IAAS servers without a Karyon client

Linux server: Enable SSH with certificate‑based authentication and use fail2ban to automatically block unauthorised login attempts. This allows access from the Internet. You must request a firewall opening by creating a case in KI Self Service.

Windows server – option 1:
Use a Karyon client and KI‑VPN, then administer the server as usual via RDP, VNC or similar.

Windows server – option 2:
Use KI‑VDI, sign in with your KI ID, and then administer the server as usual via RDP, VNC or similar.

Working with large data volumes and storage

Use KI’s object storage (S3) or file servers together with a Karyon client. Note that working directly against a file server over VPN is never optimal due to performance limitations.

If you need active interaction with an internal file server and large datasets, you should be physically on campus or instead use an IaaS/IaaS+ solution.

If you need access to specific P:\ or L:\ folders

Access to internal file servers (file storage) such as P: or L: drives is restricted to managed Karyon clients for security reasons.

L drives are accessible from lab equipment connected to the lab network. If you have a computer on the lab network, you can access L drives when on campus.

P drives contain protected data and are accessible only via managed Karyon clients.

External partners and data handling

External partners requiring access to shared data

KI provides specific services for sharing data with external parties, such as MFT and SciShare.

If the external party needs to actively work with the same data, they must be affiliated with KI and use a KI identity together with a Karyon client, or access the environment via KI‑VDI.

Teams and SharePoint as collaboration platforms

Teams and SharePoint collaboration spaces can be used to invite external parties to work with your data, provided that the necessary approvals are in place (ethical approval, data management plan, GDPR compliance, and so forth).

External consultants requiring access to internal systems for support

Use KI‑VDI. The consultant (using a support consultant account) logs into a VDI client and then proceeds to the internal system that needs to be supported.