I've been working on this for a while, without much luck.
I'm using port forwarding to expose the ssh port on internal virtual machine to the outside world (port 8000 on the host). The host machine is Ubuntu 18.04LTS, 132 GB ram, AMD Epic 16/4 cores. The VM is Debian 11.
I am using ufw for general protection of the host. Connections can only be made from the campus network, and outside users have to vpn to the campus network before connecting. There are two subnets, one is a class B subnet that covers the entire campus, the other is the 10.0.0.0/8 which is used by the campus vpn and wifi and is routed inside the university. The planned use of the environment is for teaching 3rd year OS course.
I used https://www.cyberciti.biz/faq/how-to-configure-ufw-to-forward-port-80443-to-internal-server-hosted-on-lan/ as a basis, as well as a lot of other pages, not all of which I remember the URL.
The internal private network is 192.168.101.x. The /etc/ufw/before.rules I'm using are:
*nat
:PREROUTING ACCEPT [0:0]
# forward hostIP from campusBSubnet port 8000 to 192.168.1.101:22
# forward hostIP from campusVPNSubnet port 8000 to 192.168.1.101:22
-A PREROUTING -i br0 -d HostIP -s campusBSubnet -p tcp --dport 8000 -j DNAT --to-destination 192.168.101.2:22
-A PREROUTING -i br0 -d HostIP -s campusVPNSubnet -p tcp --dport 8000 -j DNAT --to-destination 192.168.101.2:22
# setup routing
-A POSTROUTING -s 192.168.101.0/24 ! -d 192.168.101.0/24 -j MASQUERADE
COMMIT
... rest of before.rules
One modification from the referenced webpage was the addition of the source address restriction as the *nat rule seemed to bypass the ufw default deny and allow external address to access the forwarded port.
This works, and allows me to ssh into the VM from outside with ssh -p 8000 HostName. Things seem to work well, except that x2go doesn't really work at all. The initial display shows up (and a dialog asking for the root password to create a Color Display Device), and after that, nada, no response. The x2go client complains about no response after x seconds, where x is ~30 seconds.
I moved the vm to a bridged interface and gave it an external IP address, and connected directly to the vm over the bridge. Everything works fine. There is a small amount of lag on the x2go interface, but not really noticeable, but on the private network nada. I did some speed comparisons using scp to copy a large file to and from the VM both on the bridge and through the port forwarding, and while the port forwarding was a bit slower, it there was less than 10% difference in speed for the bulk transfer.
I am at a bit of a loss why there should be such a difference in performance between the port forwarding option and the bridged version. This is testing before setting up on a server with 192 GB ram and 180 cores for the corse. We will be running approximately 90 vms at a time out of 180 (two lab session), and we really can't give out 180 ipv4 addresses just for one course, so the bridge configuration is not really an option.
There appears to be a wide variety of options for x2go, and I really haven't look at any of those, so if that is a possible solution, I wouldn't mine a pointer to which of the many options are available.
Based on one of the previous pages (which was either server fault or stack overflow) indicated that the built in libvirt NAT causes problems with port forwarding, so I used a routed private network and the third post routing rule in the figure above. Same performance issues.
Right now my backup strategy is visual studio code using the ssh option to edit on an external machine and compile and run on the vm. This seems to work fine over the ssh port forwarding.
Thanks.
