View Full Version : Port Forwarding public port 81 to 9000

Richard Grant
2005-01-23, 11:43
> Wow. Thanks for the info. Sounds quite straightforward; I'll
> give it a go.

Hope it works out.

> >You can obviously add as many services as you like.. all traffic will be
> >encrypted between your work computer and your home network. Perhaps you'd
> >also like to install TightVNC on all your home computers so you
> can control
> >them all as if you were actually there.
> >
> I've been trying to use Windows Remote Desktop, but I guess the
> problem there is that the client tries to use a fixed port, and
> the work firewall prevents the use of the port. So I might try
> TightVNC instead.

If you get the initial configuration done.. just make a tunnel in PuTTY

3389 -> 192.168.0.xxx : 3389

Where "xxx" is the IP of the machine to which you want to gain access with
Remote Desktop. You could then just play with the tunnel to switch between
machines. Remote Desktop is hard coded to make client connections through
3389 while TightVNC and standard VNC allow you to specify the client
connection port like:

8000 -> : 5900
8001 -> : 5900
8002 -> : 5900

Then you can save stub "name.vnc" files on your desktop pointing to, for
example, "localhost:8000". So VNC is more flexible in creating static links.
Just note that Tight and standard VNC require you to disable the Fast User
Switching service on the server machines that you want to connect to, and
you can actually use both Remote Desktop and VNC to have a redundant setup
should something go wrong.

Given the information above, a working configuration, and the following
lifted from the list archives, a clever sort could arrange to have a
Squeezebox in LA connect to a SlimServer in NY.

"Client connects to Server on ports 3483 (control), 9000 (music data)"
"Server connects to Client on port 31337 (firmware updates)"
"Port 9090 isn't actually used by the players; it's an alternative to"
"the HTTP interface for control of SlimServer by other programs."

If you want to try something like the above, remember that many list posts
suggest that it is *not* recommended to perform firmware upgrades over WAN