Situation:
We, as the pioneering researchers(!), have a small network in our lab and the university has provided Internet access that let us access to privileged scientific resources like IEEE, ScienceDirect, etc.
I am looking for a way to connect to lab network through Internet when we are away and have this privileged access (and also be able to remotely connect to the lab computers and simulate some things).
Sadly, our network is behind the NAT-server of university, so there is no chance in a pure VPN-Server solution. There is no chance to configure the main NAT-server of university neither.
Possible Solution:
I have tried Hamachi VPN software, but as I realized Hamachi does not establish a VPN Server behind a NAT. It is actually a peer-to-peer solution for computers behind NATs over the Internet.
One Hamachi-based solution is to configure one of the lab computers as a VPN server and installing Hamachi on it. Then the distant users should install and run Hamachi on their computers and then connect to first the Virtual Hamachi Network and then the VPN-Server.
Problems of proposed solution:
But there is some problems about this:
- Will Hamachi really work on a VPNServer? Not surprisingly, Some users use linux :) Is there any linux-based Hamachi software for them?
- The procedure of connecting to the lab internal network is a little bit complex, and as you know researchers are really not good at computers. Is there any way to KISS (S imple and S traightforward)
- The Hamachi software causes some mistakes in my routing table. Specifically, sometimes I lose internet access when I connect to our Hamachi Virtual Network and I have to reconnect. Is this a common problem with Hamachi? If yes, too bad because this would confuse and annoy other less-experienced users.
Future work:
Do you know any better free solution to connect to the workplace LAN that is behind a NAT?
Some words about legality:
Just as SvenW said, actions like this is a may raise some legal concerns. I asked about this and sysadmins said it is okay as far as we don't spread this access to the other people. Our team is consisted of 14 people and each of us can have his username/password to connect to. Therefore, all the activities can be logged and any misuse can be traced.
Short answer: Ask your networking people if they accept it, otherwise stop right now.
Long answer:
It is highly likely that what you want to do is not covered by the contracts between your university and ScienceDirect et al. and could lead to the termination of those contracts and possible heavy penalties if you get uncovered. Depending on where you live, it might even end in the termination of your contract...
If your networking people don't offer any proxy and/or VPN access, there will be a reason for it, so it's unwise to try to sneak your way around this. Or maybe they even do and you just don't know it - have you tried asking?
Finally: Contrary to what you might think, most admins are trying to be as helpful as possible, but if we say something is not possible, there is usual a good reason for it, which might be technical, legal, monetary of even the additional workload it would create which can't be handled with the staff at hand.
First and foremost, I agree with SvenW's answer. I wouldn't even consider something like this without sysadmin recognition and approval. That being said, there might be a few solutions.
You could use a permanent gateway host: have a system outside your university's network with a reverse ssh-tunnel set up. Have a system internal to the network ssh out to your "gateway" machine, and use options like -R8000:127.0.0.1:8000 to provide a tunnel into your university network. Run Squid on your university system and you can your own proxy. Of course, be sure to properly secure it and restrict access to just your team. You could also run OpenVPN and have the advantages of a full VPN, at the cost of some speed.
There are packages that can maintain SSH tunnels and automatically restart dead connections, but if you set your keepalives well and use key-based authentication you should have minimal service disruptions.
try TeamViewer. It'll get past most NATs and firewalls, and it is dead simple to use. If your sysadmins are as lazy as you say, they would not even have heard of TeamViewer.