How to run a Wolfram remote kernel from a laptop over VPN

You connect the VPN, open the notebook, and expect the heavy cell to run on the server. In practice the tunnel only carries packets. It does not install an evaluator, grant a license, or choose which machine executes the code. Those are three separate things, and a remote-kernel workflow needs all three before the first calculation is trustworthy.

The myth: a VPN connection is the setup

The VPN supplies a network path between the laptop and the server. That is useful and often necessary, because the launch channel and the kernel connection have to reach the remote host. It says nothing about whether a Wolfram kernel exists on that host, whether the license allows a second concurrent process, or whether the front end is configured to use it.

A managed laptop may carry only the front end, with the entitlement attached to the server. The reverse also happens: a desktop license on the laptop does not authorize a kernel on shared infrastructure. Neither case is fixed by reconnecting the tunnel.

Test the assumption early. Evaluate $MachineName in a fresh notebook and compare the answer with the host you expect. If it returns the laptop's name, the cell ran locally no matter how healthy the VPN looks.

Separate the front end from the evaluator

The front end is the window: it edits cells, renders output and stores the notebook file. The kernel is the process that evaluates expressions and holds definitions in memory. Closing the front end does not move the kernel, and saving the notebook does not save the kernel's state.

Once a remote kernel is attached, the notebook's file location and the kernel's working directory are different things. Directory[] reports the evaluator's directory, which is the path that matters for Import, Export and relative file names. A dataset sitting next to the notebook on the laptop is not visible to a kernel running on another machine.

Decide how data will reach the server before you write the analysis: a shared mounted location, an approved transfer step, or a database the server can reach directly. The choice affects reproducibility, because a notebook that depends on a laptop path will fail the next time someone else runs it.

Launch the kernel through an approved channel

Wolfram's remote-kernel guide describes adding a kernel entry, selecting the remote machine and launching through SSH. The executable path and arguments in the example belong to that product workflow; adapt them to the host and version the administrator names rather than pasting them unchanged.

Host identity is part of the setup. Verify the SSH host key through the organization's process, use the issued authentication method, and keep private keys and passwords out of notebook files that get shared or committed. A notebook that contains a launch command with a password is a credential leak, not a convenience.

Do not open a WSTP listener to the internet as a shortcut. The supported pattern is the SSH launch, which keeps the kernel channel inside an authenticated connection. If the network team has approved a different transport, use that instead, but treat an exposed evaluator port as a design change rather than a troubleshooting step.

Check entitlement, data and output size first

Confirm with the license owner that the server may run a kernel for this user and that concurrent sessions are allowed. Remote compute is often licensed separately from the desktop front end, and a failed launch caused by entitlement looks similar to a failed SSH command until someone reads the server's message.

Then estimate the result size. A kernel that returns a multi-gigabyte expression sends it across the launch and kernel channel to the front end, which can stall or exhaust memory on the laptop. Keep heavy aggregation on the server and return summaries, or write large results to a server path and transfer them deliberately.

Record the executable path, the launch arguments and the working directory in the notebook's setup notes. The next user then reproduces the arrangement instead of rediscovering which of five possible paths the server uses.

Diagnose the stages in order

Five stages have to succeed, and each one has a distinct test. Start from the laptop and stop at the first failure instead of changing several settings at once:

nc -vz research.example.edu 22
ssh -v [email protected] 'hostname; command -v wolframscript'
ssh [email protected] 'wolframscript -code "$MachineName"'

A failed TCP check points at routing, DNS or the VPN's allowed destinations. A successful TCP check with a failed SSH login points at authentication or host-key policy. A login that works but finds no executable points at the kernel installation or the path the front end was given. A kernel that starts but never connects points at the launch arguments or the local firewall.

Preserve the first meaningful error and send the server-side stages to the administrator who owns that machine. Repeatedly recreating the kernel entry hides which stage actually failed, and it discards the evidence the administrator needs.

What you want at the end is a window you recognize, an evaluator you can name, and an agreed route for code and files. The VPN is one component of that path, and the sooner the workflow reflects that, the less time goes into reconnecting a tunnel that was never the problem.