Preface: When I first set up this page, I knew of no other VPN solutions for OSX. Now there seem to be several, and Christoph Pfisterer has a great page on them. I have used vtun on various platforms in the past (FreeBSD and linux), and have always found it easy to set up. I'm putting this page together so that others can get this kind of thing going with less pain than I have gone through.
Goal: Because 802.11 is SO DANG INSECURE (see also http://slashdot.org/articles/01/04/27/1847237.shtml), I have put my base station outside my firewall. In order to make my shiny new iBook behave like it is on my home LAN, I set up a VPN server and connect to it. This could also be used to create a VPN to your office from home, or wherever you liked...
Requirements: You need to know a thing or two about unix sysadmin. Sorry, but I have not wrapped this all in a nice GUI or anything like that for you. You MUST be familiar with, or willing to work hard to learn about: network interfaces, IP addresses, hostnames, and maybe a little routing and nameservices, depending on what you want to accomplish. You must have the dev tools if you want to compile this stuff from scratch.
Overview: VTUN (see also http://vtun.sourceforge.net/) is a tool that creates a virtual network (with all kinds of options). It runs either as a client or server. It used a tun or tap device, neither of which is available on stock OSX systems. To create tun devices, I used a kernel extension [that no longer seems to be available]. The version I supply does not seem to be the same as is available from this site, though I'm sure they come from the same root. I do provide a tarball of the binary below, but do not have source for my version. What VTUN actually does is bind a new IP address on each side of the connection (one for server, and one for client). All communication through these addresses will be encrypted and/or compressed.
The TUN driver: Christoph Pfisterer has improved upon the TUN drivers and has a page with source and binaries at http://chrisp.de/en/projects/tunnel.html. I STILL have not tried them out, but they come highly recommended.
The binaries:
Either grab and install the binaries, or grab, patch, and install the sources (and grab the tunnel.kext binary). Everything will install into /usr/local/... in either case. Once you've done that, you're ready to start editing your config files. vtun ships with examples, but they are more complicated than I like, so here are some easier ones:
Edit the conf files. MAKE SURE THE PASSWORDS AND CONFIG NAMES MATCH.
On your server, run something like this (as root):
(You only need to load the kernel mod once)
kextload tunnel.kext
vtund -n -s -f vtund.server.conf
This will run the sever in debug mode (-n flag).
On the client, run something like this (as root):
(You only need to load the kernel mod once)
kextload tunnel.kext
vtund -n -f vtund.client.conf MyConfigName MyServerName_OR_IPAddress
NOTE: unloading this kernel extension tends to hang your machine - so I don't unload it.
You should now be able to ping the remote TUN interface addresses from both machines. Of course, you should also be able to do anything else from/to the other machine that you would normally do.
Notes: I happen to use a FreeBSD box as my server. I also NEVER leave the vtun port visible to the outside world. What I tend to do is tunnel it over ssh by doing something like this:
ssh -L someport:localhost:5000 MyServer.MyDomain.com
vtund -P someport MyConfig localhost
I also have encryption turned off when I use this method, since ssh does the encrypting already.
Some people thing that vtun is not secure enough alone. Your call...
I have only run vtun in server mode on OSX briefly, though it seemed to work fine for me. If you try this and find it works well, please let me know.
Credit: None of this stuff is my work. The only effort I have made is the vtun patch to build on OSX, gathering everything together, and putting up this webpage. Frankly, I know very little about how most of these things work, and couldn't write a TCP tunnel program or kernel extension without a stack of manuals and lots of time.
Feedback: If you find this useful, but think it could be more clear; or if you find this unclear and would like it to be more useful, please let me know. I'm also curious to know how one might affect things like the location manager from the commandline, as well as netinfo bindings (to parents, etc). If you manage any location or NetInfo trickyness in association with this stuff, I'd love to hear about it and share the info.
Phrases to catch a search engine's attention: