Wednesday, June 11, 2003

Every now and then, I'll be on the road somewhere and I'll want to access the filesystem on one of the system's behind the firewall on my home LAN. The "firewall" is actually just a basic LinkSys Cable/DSL router that does Network Address Translation. By default and because it does NAT, none of the boxes behind the firewall are directly accessible from the outside world.

Gradually, I have made accessing the internal boxes on my home LAN easier while not actually sacrificing security (that is, nothing is open but SSH).

The first step was to set up port forwarding on the LinkSys box such that any attempt to connect to the SSH port (22) to an internal OS X box that is set to never sleep and has remote login enabled.

Of course, referring to my home LAN by IP address is no fun, so then I registered my system with DynDNS. The service is free, but supported by donations (of which I did!).

At this point, I have ssh based access to a system on my LAN and, from there, I can ssh to the other system's on the LAN.

Handy, but not exactly user friendly. There are times where all I really want to do is mount a filesystem and drag-n-drop some photos to a relative's system.

No problem -- just use SSH port forwarding:

ssh -C -L 10548: -N

With the above active, I can then go to the finder and pass 'afp://localhost:10548/' to the 'connect to server' dialog and it just works.

But that still requires that I know the IP address of the machine I want that is behind the firewall. Easy enough for the fixed IP server, but not so easy for the rest of the machines-- all of which pick up their IP via DHCP.

Then I remembered that hostnames provided within the -L port forwarding specification of ssh are resolved on the machine you are ssh'ing into!

So, the above becomes (bumbox is the name of my TiBook):

ssh -C -L 10548:bumbox.local.:548 -N

And it just works! Neat!

But, wait, there's more....

When sitting behind a corporate firewall (or many hotel firewalls, these days), it can often be very difficult to send email using your normal outbound email account. Because of spam, there are very few open relays available any more -- at least, very few open relays that you would want to pass your email through.

Typically, if you have a cable modem or the like, they will provide you with an open relay address that works only if you are connected directly to their system. When I used as my primary account, I could send email as if it were from by directly connecting to my ISP's -- earthlink's or optonline's -- SMTP server.

By changing the above command to the following:

ssh -C -L -N

I can then set the outbound mailhost -- the smtp host -- of my various mail accounts to port 1025 of localhost. That port will be transparently forwarded to port 25-- the standard SMTP port-- of the host but only after the traffic has been routed through my home LAN. This allows me to legitimately relay email in the same fashion that I would at home, but from anywhere in the world (from which I can successfully ssh)!

Furthermore, it is obviously secure and has the added advantage of being compressed. Since email is mostly plain text, the compression ratios are often around 70% to 80%.

Similar tricks can be used to forward connections to IMAP (port 143) and POP (110 or 109 -- I don't use Pop anymore).

Of course, you can combine as many -L forwarding sets on the command line as you want.

If you don't trust the web proxy on your LAN (I wouldn't in either a hotel or a corporate environment), turn on Apache's caching proxy server or install squid, then use port forwarding to forward a port on your local machine to the proxy port on the remote proxy server. Then, point your browser (or OS) to use the local port as the proxy server. This allows for secure, non-monitor-able, transparent, surfing from any location.
3:50:02 PM  pontificate