Work VPN on a Raspberry Pi: Ask These Questions First

Four answers from the employer decide whether a Pi can join the work VPN: which gateway protocol it speaks, which operating systems and architectures it supports, how authentication has to happen, and whether a client other than the official one is permitted. A portal URL and the word Linux settle none of them. Ask before downloading anything, because the answers change which package you install and whether a headless setup is viable at all.

Write the four answers down. The rest of this is what each one changes.

The Gateway Protocol Decides the Client

The gateway speaks one or more protocols, and the client must implement the one your organization actually runs. OpenConnect is an independent implementation that began with Cisco AnyConnect compatibility and now covers several other enterprise gateways; it is not the vendor's branded client, and protocol compatibility does not guarantee support for every gateway feature, posture check or device policy. Confirm the protocol with the network team rather than inferring it from the portal's URL. Then confirm that the employer accepts this client for this deployment.

Compatibility evidence has to come from the employer's documentation or from a colleague who has done it on the same model, not from a package existing in a repository.

Architecture Is Not a Detail

Record the Pi's OS release and user-space architecture, the client version you intend to use, and where that package comes from. An x86 installer does not become suitable for another architecture because its filename changed, and a vendor client that ships only x86 builds cannot run on the Pi at all. That single fact can settle the whole question before authentication is even discussed. Check the package source's maintenance rather than installing a stray binary from a forum thread.

A 64-bit user space on a 64-bit kernel is the simple case; a 32-bit user space on a 64-bit board is where people install the wrong package. dpkg --print-architecture and uname -m answer both halves in one line each.

Authentication Decides the Workflow

Passwords, MFA and browser-mediated sign-in each impose a workflow of their own. A certificate held on a hardware token may need a driver the Pi does not have, while an SSO flow may open a browser window that a headless session cannot show. Some gateways offer a device-code or manual-copy path for exactly that case, and some do not. Ask which method the organization supports for a headless Linux host, then test it before depending on it.

Frontend integration is a separate choice from authentication. A NetworkManager plugin can arrange a connection and store its secrets, but it cannot make an unsupported authentication method compatible. Keep those two questions apart.

Keep the Employer's Boundary Intact

If the organization requires its official client, a managed device or a supported distribution, follow that requirement or request an approved alternative. Disabling certificate checks, imitating posture results or turning off endpoint controls to make another client appear accepted converts a compatibility problem into a policy violation. Keep passwords, session cookies and private keys out of shell history and chat transcripts. A working challenge-response is not permission to publish the session material.

After an approved enrolment, confirm private DNS, the intended resources, a denied resource and reconnection, all from the Pi itself. A logged-in tunnel can still route incorrectly or lack an authorization.

The deliverable is a supportable agreement with a named owner: which client, which version, which enrolment path. That beats installing the vendor-adjacent client and hoping the remaining requirements turn out to be optional.