I'm trying to connect my FrontEnd session to remote kernel. Manual connection works by creating LinkObject like so:

link = LinkCreate["[email protected],[email protected]", LinkMode -> Listen, LinkProtocol -> "TCPIP"]

Connect to remote machine forwarding ports 8000 and 8001:

ssh -R8000: -R8001: user@host


wolfram -wstp -LinkMode Connect -LinkProtocol TCPIP -LinkName [email protected],[email protected]

Then locally this works as expected:

(*InputNamePacket["In[1]:= "]*)

LinkWrite[link, Unevaluated@EvaluatePacket[$MachineName]]


But any attempt to connect my FrontEnd results in a frozen evaluating cell that doesn't return anything. Even though the connection is clearly there, because it drops remotely after closing it locally.

I've tried many things: Evaluation -> Kernel Configuration Options, the tunnel.sh script suggested in other answers, assigning to $ParentLink, nothing works!

Remote machine has linux with Wolfram Engine For Developers installed. And I'm running WolframDesktop 12.0 locally on Mac.

EDIT: I've managed to get it working with Raw MathLink connection option ("RawMathLinkProgram" -> True). But it's pretty limited, no graphics, just text output.

EDIT: Suprisingly it works if I connect to my other laptop within my home network. It also has Ubuntu and docker with Wolfram Engine. But if I try basically the same steps with a cloud server, it refuses to work (unless it's raw mathlink connection).

Reverse connection:

ssh -L8000: -L8001: user@host

Replace Connect with Listen

wolfram -wstp -LinkMode Listen -LinkProtocol TCPIP -LinkName [email protected],[email protected]

And local Kernel Configuration:

-LinkMode Connect -LinkProtocol TCPIP -LinkName [email protected],[email protected]

Same result, local FrontEnd just crashes if I connect to remote cloud machine, but works with my laptop (shrug)

Very certain that it's a bug at this point, some low level protocol discrepancies maybe.

  • $\begingroup$ I would be surprised if this works when you try to use a "Wolfram Engine for Developers" which I interpret as being the "free Wolfram Kernel". AFAIK, the free version comes explicitly without a front end because you are not allowed to use one. The easiest way to test this is to make a "remote" kernel which uses an ssh to your current machine where you have a real kernel. If this works, chances are good that indeed the free version kernel actively prevents you from connecting with a FE. $\endgroup$
    – halirutan
    Commented Nov 4, 2019 at 0:24
  • $\begingroup$ @halirutan Connecting to local free kernel works fine, so it's not limited to running only without front end. It must be something else, no idea what. $\endgroup$
    – swish
    Commented Nov 4, 2019 at 0:36
  • $\begingroup$ But your "local free kernel" might be backed by a real license. Can you check your $ActivationKey for your local free kernel and ensure that it doesn't use your bought license? $\endgroup$
    – halirutan
    Commented Nov 4, 2019 at 0:42
  • $\begingroup$ @halirutan No, I'm pretty sure, it is running from a docker container. $\endgroup$
    – swish
    Commented Nov 4, 2019 at 0:57
  • 2
    $\begingroup$ @swish there are actually three MathLink connections when the FrontEnd establishes a connection with the Kernel. So in your example, only the main link would be tunneled. The other two have no chance of every being established. Turning on "Raw MathLink connection", disables the additional two links. Which also means that certain functionality is not available. $\endgroup$
    – ihojnicki
    Commented Aug 3, 2020 at 17:22

1 Answer 1


Sorry this is not an answer but the text goes too long for the comment.

There'a whole bunch of things that could go wrong with remote kernels in my experience.

Basically FE starts remote kernel and asks it to connect to the FE, passing FE addresses and ports in the link parameters. In my case the remote command line looks like:

WolframKernel -wstp -LinkMode Connect -LinkProtocol TCPIP -LinkName [email protected],61518

The ports (61517 & 61518) are randomly chosen by the FE so it's hard to really use reverse forwarding via ssh (tunnel.sh tries to do this by parsing command line options. I was unable to make it work though).

Please note the reverse address ( in my case) that the kernel should be able to connect to. It's not always the case so check if it is accessible from the machine where the remote kernel runs.

Even if you have not an ssh link but the full blown VPN connection to the remote system there can be another interesting problem:

The reverse address is chosen by FE using some heuristic and is based on the address on a remote machine:


But please note the following:

remote kernel configuration window

Even if you're using "Advanced" group of dialog options the magic that choses reverse address uses "Remote host" field to select the base interfaces to use for kernel reverse connection.

And last but not least: 12.0 had a "feature" that changes to "Kernel Configuration" dialog were not always saved even if you reopen the dialog and see intended configuration. So you may want to double check if the settings are in your Kernel/init.m file.

Hope some of the above will help.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.