If you, like me, have the need of accessing your development box from a remote site and in a reasonably "secure" manner, then you can be interested in reading on and hopefully you'll be able to adapt the following steps to your specific environment.
This exercise had at least two goals:
- to be able to access my Oracle Application Express development environment from a Windows client without the need of exposing the web server to the internet.
- to minimize the network traffic by using a simple browser instead of a VNC client, while still being able to open a VNC session in case of need. This was especially important to me as i may need to access my server by using a roaming connection through my mobile phone and you know how much they charge for such services.
Soon after completing these the original two goals, it came up to my mind to try to configure a remote SQLDeveloper connection as well, whose details can be found at the end of this posting.
Setting up the SSH tunnel.
On the Mac Pro side first i needed to enable the Remote Login service (SSH). This service uses port 22 and is part of the standard Mac OSX edition (Thanks Steve!).
When you enable this service, the corresponding port is also opened in the Mac firewall.
As my network is part of a larger network where i must explicitly request the ISP for opening a port, i had to ask them for a public IP mapped to the local address of the Mac server where is sufficient to have only port 22 open.
Setting up the HTTP client to server forwarding:
On the Windows XP client i installed Bitvise Tunnelier. This is an excellent product that enables you to easily set up SSH tunnels with IP and port forwarding, moreover is free for individual use.
Most of the configuration is carried out on the client side, so all i need to do is to enter a few parameters in Tunnelier:
- user and password for authenticating on the Mac (see picture above).
- public IP address and port of the SSH server (see picture above).
- IP address and port of the client that should be forwarded to the remote server (127.0.0.2 on port 8080, see line 2 of picture below)
- IP address and port of the remote server where Apex is running (192.168.1.4 on port 8080, see line 2 of picture below).
- When you use IP address forwarding, the IP doesn't need to be the IP of the machine where SSH is running, indeed the machine running Apex is a linux xubuntu virtual machine running on the Mac under VMWare Fusion having its own IP address (192.168.1.4).
- The TCP port on the client can be different from the port forwarded to the server. For my own taste i decided to use a fake address (127.0.0.2) while retaining the same destination port number, but a combination like 127.0.0.1 on port 8081 would work equally well for accessing the remote Apex.
Given this configuration, i can now access Apex from a remote site by starting a Tunnelier session and simply entering the following URL in the browser:
http://127.0.0.2:8080/apex/f?p=4550If you don't like using straight IP addresses, then you could edit the HOSTS file in (%systemroot%\system32\drivers\etc) and add a line like the following:
127.0.0.2 remotehost
this will allow you to specify the URL as follows:
http://remotehost:8080/apex/f?p=4550
Configuration of VNC:
In a very similar fashion i've also set up VNC connectivity.
This was a good opportunity to try out a few Windows VNC clients and after some testing i picked RealVNC.
This lightweight viewer is fast and free, it's made up of a single executable file, so you don't need to install anything and you can carry it on a USB key, moreover it also allows for window scaling, a useful feature because the gorgeous Apple cinema display doesn't fit well on most screens ;-)
Again, the configuration in Tunnelier is fairly straightforward and consists of two additional parameters (see line 1 of picture above) because the SSH configuration remains the same as above:
- IP address and VNC port of the client (127.0.0.2 on port 5901)
- IP address and port of the remote server where OSX Vine Server is running (127.0.0.1 on port 5901).
Please note that:
- the standard VNC port is 5900, however Apple Remote Desktop is using that port so i preferred to switch to 5901 for the reason i explain later on.
- in certain environments it's not necessary to use IP/port forwarding for using VNC clients, but this is just another security measure as the VNC server is configured to accept only connections from localhost (127.0.0.1), so the IP/port forwarding combined with SSH tunneling does the trick, that is to transform a remote connection into a local one.
I could have used Apple Remote Desktop as VNC server and indeed i've made a few tests with satisfactory results, however i decided to install Vine Server because it gives me the additional possibility of opening multiple sessions against different OSX users.
As i configured Vine Server to work on port 5901, Apple Remote Desktop is still available on port 5900.
For those who want to perform a similar configuration on platforms other than Mac OS X, i guess they must install either a Unix or Windows version of RealVNC server or TightVNC server. For Windows platforms it's also necessary to install a SSH server first like Bitvise WinSSHD. I didn't investigate if there are free SSH servers for Windows but there should be something out there.
Last but not least, let's have a look at how to configure the connectivity for using SQLDeveloper through a SSH tunnel.
All you need to do, once you have established the SSH connection as explained earlier, is to add IP/port forwarding of whatever port you prefer to use (why not 127.0.0.2 on port 1521, so i can still access my XE db at 127.0.0.1 on port 1521) to the remote server IP address and port. In my case Oracle doesn't run on the same server where i opened the SSH tunnel but, as i've mentioned earlier, on a VM (192.168.1.4), see line 3 of the picture above.
Note that if the oracle database and SSH service were running on the same server, then i could replace 192.168.1.4 with 127.0.0.1 in the Tunnelier configuration screens above.
Finally, let's peek at the connection property's screen in SQLDeveloper:
Again, if you prefer to use the DNS defined locally in the HOSTS file, you can specify remotehost instead:
Accessing an Oracle database running on Windows (instead of Linux as in this case) from a remote client via SQLDeveloper, would most likely require the setting of the environment variable called USE_SHARED_SOCKET in order to force the communication to occur on the listener port only.
