More info is needed, really.

Yes you coudl ssh there and use the local Emacs (v23 apparently.)

If ssh is supported like that, then local to you Emacs (v 29 or whatever) over Tramp/ssh should work fine as well (the F5 load balancer deep packet inspection wouldn’t see the different; Tramp is just ssh’ing and running commands same as a user would.)

You could also try sshfs (map a local filesystem to a remote mount over ssh) but in my experience thats really slow.

You could run an Emacs on the remote, with X11 projection to your laptop, over ssh tunnel, but that’d likely be slow, and Emacs 23 is ancient :)

… so a local to you Emacs 29 with Tramp over ssh to the remote should likely work, but it depends on some other things; they _could_ block it, but not likely, assuming you can ssh there yourself.

Now, if theres a jumpserver or something, that could be a problem (2FA type challenges in the middle) but multi-hop ssh tramp could do it…

Another question is … why the heck are they stuck at Emacs 23, which is probably 10+ years old. Thats a security risk right there they should be happy to remedy :)

It might be that they use VPN to access SSH. You can try to telnet to the server port 22 and see if you get to the prompt which indicates port is open. If telnet hangs for a minute and then complains about timeout on connection attempt then you probably need to find who’s responsible for VPN and try to get one.

Interesting! I have so many questions :D Why only Emacs 23? Is that the version that is installed on the server? Emacs 23 dates back to 2009 and if they say it’s the only available version I suspect that the system is outdated long time ago. Could mean that security flaws are present, and those might be your ticket to having it upgraded along with Emacs ;)

I’m not sure about the connection, but in case you don’t know, Emacs has tramp. Simplified it downloads files from a remote server over ssh so you can edit them with your own config, and then uploads them once you save.

One minimal option is to run emacs locally and simply mount the remote files with sshfs - then at least for editing you can use the latest and greatest emacs. Loading and saving can often be a bit slower than local obviously. This also breaks compile integration — although even there an ssh wrapper around a make (or whatever) call would probably work - I just haven’t tried it.

In a similar situation on Unix, I’ve installed my own copy of emacs in my home directory on the affected machine. No idea whether that’s feasible on Windows.

It’s all probably against the policy but if there is a free port open, you can start ssh. If not, I agree there is no way to use local emacs. I would just try to compile emacs on the remote machine which is difficult restrict if the direct or indirect internet access is allowed.