We have a very specific short-term need: deploy a system into a room without network access so that a building automation system can be installed and the host machine can be accessed remotely.
Givens:
* A network will be installed into this room, but not soon enough for the need for building automation system hardware.
* The machine needs to run Windows 2003 for the building automation system software
* The building automation system contractors need to fit out and access the system remotely from the Internet until such time as a permanent network is installed.
Components:
* A Dell R200 with DRAC4 installed
* D-Link DIR-450 IEEE 802.3/3u, IEEE 802.11b/g 3G Mobile Router for EV-DO Networks
* Cygwin w/autossh
* MyEnTunnel
* putty plink
* rdesktop
* VNC
So, what do we do? First step, we figure out what network options we have. Wired is right out for a couple of months for reasons of construction and deployment, but the room already has sufficient mechanical gear to necessitate getting the requisite controls in place and tested. It turns out that Verizon wireless is a viable access mechanism in this room, soon to be an active disaster recovery site.
It turns out that Dlink makes an access point that you can plug a Verizon wireless card into and use WiFi or LAN out the other side, routing between them. We purchased one of these as an exterior access method and connected the R200 to one of the available ethernet ports. The DIR-450 was setup to automatically connect to the internet over VZW 3G when an outbound connection was initiated. The access point hands out DHCP to the host containing the DNS forwarding and default route necessary to get to the Internet, and it gives the host a NAT’d address.
On the R200 in the lab, the DRAC4 interface was used to access the host via the KVM console so that access via the access point to the internet could be confirmed working without interference. eth0 was connected to our management network so that we could turn it on to transfer files in to host (e.g. cygwin) and then turn it off again.
We confirmed that internet access was working. Great! This would have been mission accomplished had we not discovered that VZW has specific firewall rules prohibiting inbound service connections to hosts. Planned work-around: ssh with reverse tunnel port forwarding to a public host so that the contractors can connect from anywhere.
Through the LOPSA lists I discovered a neat free program called MyEnTunnel that is capable of running as a Windows service. It uses plink (part of the putty ssh suite) and keys to automatically start and keep connections running. It has configurable parameters to allow for how often the connection reestablishes, where the private/public key file is held, ports to forward both on the local side and the remote side, and more. I managed to get this program working with a profile and it performed nominally.
The next step was to turn this into a service. This is even a part of MyEnTunnel’s design by making a special profile called myentunnel-service with the various parts holding the port forwarding, the .ini file, and the keys. I tried many permutations to get this to work.
* Straight service – The service would run and would spawn plink, but plink would never connect. Netstat -a showed that the port to the remote host was being opened with a TCP_SYN, but the remote host never saw anything from the access point (remember, there’s a layer of NAT in between). ”’Theory:”’ not enough permission for the System Service account to use TCP ports.
* Setting up a .bat file calling myentunnel.exe with the profile as an argument. This worked great when run by itself, so I tried to convert it to a service. Then I used ”mmc” to add a Startup script to run at machine boot that called the bat file. ”’Problem:”’ when you have a program that is designed to run ”permanently and persistently”, the startup script process never ends, and you never get a login prompt. Ouch.
* I found a .vbs script that is capable of running a .bat file in the background. I tested it from the command line. Yes! This, once again, seems to solve the problem. So I made this into the startup script. Stymied again! I can see the .vbs executed from the console (thanks drac4), but for some reason myentunnel and plink don’t start and stay running.
After a couple of days of trying, I gave up on myentunnel and went back to Cygwin. Within an hour I had the port forwarding service setup in Cygwin. Within 2 hours I had the service confirmed running through reboots, and the port forwarding working for 3389, 5900, and 22. After a few hours work, everything is working perfectly, most of that was in getting the sshd service to run and stay running on windows, and a good deal of that was failure to carefully read, understand, and follow the instructions to the letter.
Here is a very succinct guide to getting the job done in cygwin: http://www.matthanger.net/2008/04/creating-persistent-ssh-tunnels-in.html
Now, through use of a relay box, we can:
# use rdesktop over the internet through a reverse ssh proxy to relay box and then over VZW through access point over NAT to R200
# Same with VNC
# also run cygwin sshd on the R200 and directly login to the R200 using a port forward for port 2222 (obviously we can’t use 22 directly since the relay box’s native sshd uses that to effect the port forwarding solution)
As of this writing, the solution is complete and the server is ready to be boxed up and shipped to the waiting DR room and building automation system installers. When you think about it, it’s amazing that things like this work at all, but well worth sharing.