Mac OS X's built-in Virtual Private Network client and SSH offer two secure ways to tunnel in to your company or organization.
Mac OS X 10.2 includes a Virtual Private Network (VPN) client for tunneling securely into your company or organization's network, authenticating yourself, and gaining access to shared resources otherwise available only to those on site. This works regardless of whether your connection to the Internet is dial-up, DSL, cable-modem, or what-have-you. You'll sometimes hear VPNs referred to as Point-to-Point Tunneling Protocol (PPTP). Whatever you call it, previous versions of the Mac OS didn't include a VPN client, leaving you to third-party software like DigiTunnel (http://www.gracion.com/vpn/).
To initiate a VPN connection, the first step is to ensure that you're connected to the Internet in some form. Once you're online, launch Applications Internet Connect or select Open Internet Connect . . . from the Internet Connect menu bar icon, as shown in Figure 6-9.
Select File New VPN Connection Window or press Shift--P. Enter the server address, your username, and your password into the appropriate fields. Save the password to your keychain if you'll be using this connection often and don't feel like typing your password each time. Click Connect when you're ready.
One gotcha and quick fix: if you're logging into a Microsoft Windows-based VPN/PPTP server, you may need to provide the authentication realm in addition to your login. If so, tack the realm on before your login and separate the two with a \ (backslash), as shown in Figure 6-10.
Once established, all of your traffic will flow through the VPN connection. This may be a disadvantage if your home network is, for instance, faster than that running through your office; you'll be limited by the maximum throughput of both your connection to the Internet and your office's. DigiTunnel does have a workaround, sporting a split-routing feature that allows you to route requests directly to Internet sites while routing requests meant for your office via the VPN.
You may also need to fiddle with your PPTP Network settings (System Preferences Network PPTP), but most of the time you can just leave things as they were. Consult your local system administrator or Internet service provider if you're having trouble finding or reaching anything inside the destination network. Figure 6-11 shows the default PPTP Network settings.
If all goes to plan, you should start seeing your office domains and shared drives showing up in the Connect to Server window (Go Connect to Server or -K from the Finder).
When you're ready to leave the office behind, click the Disconnect button.
SSH [Hack #71] isn't only for securing interactive remote sessions; you can piggyback just about any network traffic on it, adding a wrapper of ironclad security to anything you may be doing over the network: sending and receiving email, web browsing, backing up, synchronizing two computers ? you name it.
This is called port forwarding. Think of ports as channels on a CB radio, with each service chatting away on its own channel. All web traffic communicates over port/channel 80, POP mail over port/channel 110, and SSH over port/channel 22. SSH can be set to handle data sent to a local port, performing encryption and sending the encrypted data to the remote end of the SSH connection. At the other end, it's decrypted and sent on to the appropriate port. For all intents and purposes, that remote port is masquerading as a local port.
Many a time I find myself in a strange locale without access to a mail server through which to send my outgoing mail. So, I simply tell Mail to direct all outgoing email to my local port 25 (that's the port or channel on which sendmail [Hack #82] usually lives) which, in turn, is forwarded over SSH to my mail server at work.
And it's all just a rather cryptic-looking, yet really very simple, command away:
% sudo ssh -l rael -N -L25:mailserver_at_work:25 mailserver_at_work
I (-l rael) am forwarding all traffic for local port 25 (-L25) to port 25 on my mail server at work (mailserver_at_work:25) via my mail server at work itself (mailserver_at_work). I could have routed the data via any machine that, in turn, is allowed to access the mail server at work, but since I have SSH access to the mail server itself, it only makes sense to cut out any further middlemen. The -N specifies that I'll not be running any remote commands, only forwarding the port.
You can add as many forwards as you wish to that one command line. I like to secure the mail I'm receiving as well as sending, so I can just as easily forward POP mail (port or channel 110) as well, like so:
% sudo ssh -l rael -N -L25:mailserver_at_work:25 -L110:mailserver_at_work: RETURN 110 mailserver_at_work
You'll notice that each time you do any port forwarding, you need to authenticate yourself to the remote machine; see SSH Without Passwords in [Hack #71] for a workaround. Also, since ports 25 and 110 are privileged ports, accessible only by the root user[Hack #50], you'll have to use sudo to authenticate yourself before you're able to forward them. A simple way around this is not to use privileged ports on this side of the SSH tunnel. Just about anything above 1024 will do. Picking 5000 as the base, for example, I can forward all traffic for port 25 from 5025 and 110 from 5110.
% ssh -l rael -N -L5025:mailserver_at_work:25 -L5110:mailserver_at_work: RETURN 110 mailserver_at_work
That did the trick, allowing me to avoid sudo and local authentication.