The best way to get around firewall restrictions is to implement a reverse tunnel, which would solve all of your problems.
Firewalls are built to block connections from home to workplace, but not viceversa. A reverse tunnel is a connection from work to home, which is supposed to be permanent. This connection allows a kind of piggy-back ride from home to workplace, whenever you feel like it.
You can implement reverse tunnels from both B and C (both Linux machines, no problems), provided you have an ssh server running on your Windows machine. I suggest you look up freeSSHd (as the name implies, it is free). Once you have set up on your windows machine, Google reverse tunnel linux, you will find plenty of explanations.
Another advantage of reverse tunnels is that you are not obliged to use a remote desktop connection (like ssh, which I will illustrate below), but you can use anything you want. For instance, you can use VNC instead of ssh for the piggy-back ride, and then you have a fully graphical session with your work pc from home.
If you want something quick and easy, install autossh on your Linux machines (it is a package which checks whether a given ssh connection, in your case the reverse tunnel, is up, and if it is not it automatically restarts it), then create a file called, say, auto,
make it executable, put this line in /etc/rc.local
/home/yourname/path/to/auto
and put this text into auto
#!/bin/bash
/usr/lib/autossh/autossh -M 6521 -f -p 22 -2 -N -R 8100:localhost:22 yourname@your.home.IP.address -i /home/yourname/.ssh/yourHOMEcryptokey
Now, from home, you can connect with:
ssh -Y yourname@localhost -p 8100 -i /home/yourname/.ssh/yourWORKcryptokey
The first command uses port 6521 on your home pc to check whether the reverse tunnel works. It also instructs your home pc to send to port 22 of your work pc whatever your home pc receives on port 8100. The second command tries to open an ssh seance with itself on port 8100 but, because of what I just said, this communication attempt is automatically shipped to your work pc on port 22. Thus, you are faking to connect to your own home pc, the truth is your are connecting to your work pc.
Before setting this all up, you must make sure you can connect (just once) without autossh from your work pc to your home pc.
The use of cryptography is not mandatory, but it makes the communication much safer. There are billions of guides on how to do that on any OS on Google.
You can easily remote desktop sequentially; i.e. remote from A to B, then run the remote desktop on B to C, just as if you were sitting at B. As long as you have access, rights, and an appropriate program installed, there is no inherent restriction in doing this, though you may encounter some mouse lag & similar symptoms. – Debra – 2014-04-26T07:38:32.910
Is there a more direct way? I would certainly prefer that instead of having to open up 2 connections every time. Also, I tried to remote desktop into B from A using Windows's remote desktop software, but it did not go through. What do I have to enable/configure on B to make this work? B is very old Ubuntu installation (about 6yrs ago), so 'apt-get' might be a ptoblem. And I don't have physical access to it. – user721975 – 2014-04-26T08:05:48.860
The default port for RDP -- the Windows version of remote desktop -- is 3389 -- it seems very likely that the university would block it, but that is also only for Win/MS systems. And there is not a more direct way than to remote sequentially. You might try VNC, which can be configured on both Win & Linux systems, but the university probably blocks that too. I suspect that they will defeat any common remote desktop tools, but you can try asking IT what's allowed, first. – Debra – 2014-04-26T08:20:36.733
Actually I used to be able to remote desktop to C from A directly (after getting myself on the university's VPN). I used to use VNC Viewer. So I know that remote desktop to C works. But just recently, I have been having some trouble with VPN, and hence the need to look for a temporary workaround. – user721975 – 2014-04-26T08:49:11.520
But you asked "is there a more direct way" in a university environment where most ports are going to be blocked and you no longer have access to C from outside the LAN, though apparently you verified that RDP still works to B. So whatever you do, by definition you have to go through B and it has to comply with typical university firewall restrictions. That narrows your options, which is why you get those timeouts you mention below. The most "direct" way, of course, is to go to IT and ask what you can do. – Debra – 2014-04-27T14:47:57.837