Using Supermicro IPMI behind a Proxy?
Solution 1:
I figured out it's best not to use a socks proxy for this, but instead forward all ports necessary on a localhost IP. To evade any existing services, I use a different IP than 127.0.0.1. Assuming you chose 127.0.0.2, and your server behind the proxy is 192.168.1.1, this is the ssh command to use:
ssh user@proxy-server -L127.0.0.2:443:192.168.1.1:443 -L127.0.0.2:5900:192.168.1.1:5900 -L127.0.0.2:5901:192.168.1.1:5901 -L127.0.0.2:5120:192.168.1.1:5120 -L127.0.0.2:5123:192.168.1.1:5123 -C
Then you can browse https://127.0.0.2 and use the KVM as usual.
The forwarded TCP ports are 5900 and 5901 for control and video, 5120 for virtual CD and 5123 for virtual floppy (I didn't test the latter two). Added -C for compression, though I don't know if anything sent is suitable for compression.
Another, slightly more comfortable (and, in theory, better performing) method on linux, is to use sshuttle, which transparently forwards all TCP connections via ssh using iptables and a python interpreter on the proxy-server.
sshuttle -r user@proxy-server 192.168.1.1
Hint: sshuttle is being packaged in Debian.
What I couldn't forward yet is the UDP port 623, which can be used for ipmitool, a CLI connection for IPMI. There are several tutorials on this, but none worked out for me. Anyways, Java KVM is well enough.
Solution 2:
It sounds like a VPN might actually be your best bet. Have an ACL on the router so that the only non-local traffic has to traverse the VPN and you're done. Very simple and secure as well as easy to manage.
Solution 3:
Try tsocks, it should let you run any process through a SOCKS proxy by setting LD_PRELOAD which should work in all subprocesses, see this for example usage. Of course, if you are using ssh to create a SOCKS proxy, you'll still have the UDP issue, but this should get around the subprocess issue.