IPSEC connection between Mac OS X and SonicWALL TZ 170

I got a snazzy SonicWALL TZ 170 firewall from work. It works much better than my previous Linksys firewall/router (which regularly overheated during the summer months). The SonicWALL also supports IPsec VPN. Since I'm travelling for the Thanksgiving holiday, I decided to get the VPN working with my iBook.

Although VPN Tracker has a slick interface with good defaults for numerous firewalls, $90 is too steep for me. I tried VaporSec, but I got the error message Can't get file of folder "::private:tmp" of startup disk. (-1728) and was unable to resolve it.

To get the VPN working without any extra programs, the first step was to change the VPN settings on the SonicWALL, so I:

• Chose the VPN tab from the left menu


• Edited the configuration for GroupVPN


• Under the General tab




• Chose IKE using Preshared Secret


• Entered a shared secret




• Under the Proposals tab for Phase 1




• Chose DH Group 2


• Chose AES-128 as the encryption algorithm


• Chose SHA1 as the authentication method


• Set the Life Time to 600 seconds.




• Under the Proposals tab for Phase 2




• Chose ESP as the protocol


• Chose AES-128 as the encryption method


• Chose SHA1 for the authentication method


• Enable Perfect Forward Secrecy


• Chose Group 1 for the DH Group


• Set the Life Time to 28800 seconds




• On the Advanced tab




• Disabled XAUTH authentication


• Left everything else with the defaults




• Left all the defaults on the Client tab


• Clicked OK and Enable the GroupVPN

Mac OS X comes with support for IPsec using the KAME tools racoon and setkey. The man pages for "racoon.conf" and "racoon" along with this sample configuration file helped me come up with the following configuration files:

Configuration for home.conf (for racoon).

path pre_shared_key "/etc/racoon/psk.txt";

remote anonymous {
    lifetime time 24 hour;
    exchange_mode main, aggressive, base;

    proposal {
        encryption_algorithm aes 128;
        hash_algorithm sha1;
        authentication_method pre_shared_key;
        dh_group 2;
    }
}

sainfo anonymous {
    lifetime time 12 hour;
    pfs_group 1;
    encryption_algorithm aes 128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

The file "/etc/racoon/psk.txt" contains a single line like this

69.144.112.123  this is my secret

For home.spd (configuration for setkey). In this configuration, 192.168.2.5 is the IP address of the laptop, 192.168.40.0/24 is my home network and 69.144.112.123 represents the external IP address of my SonicWALL TZ 170.

spdadd 192.168.2.0/24 192.168.40.0/24 any -P out ipsec esp/tunnel/192.168.2.5-69.144.112.123/require;
spdadd 192.168.40.0/24 192.168.2.0/24 any -P in  ipsec esp/tunnel/69.144.112.123-192.168.2.5/require;

This next part is the portion that I didn't find documented anywhere. Once I have the configuration files written, how do I make it "go" The following worked for me (when acting as root).

setkey -f home.spd
racoon -F -f home.conf

And then, in another Terminal.app window ping 192.168.40.5. By specifying -F racoon will stay in the foreground which lets me easily stop the VPN when I'm done. The ping actually makes the VPN connection. You don't really need it since any other attempt to access the remote network causes the same effect.

Notification when mutt Receives New Mail

After several months of using KDE's kmail to access my IMAP account at work, I gave up and decided instead to use the wonderful mail client mutt. I wanted to switch because using 29M of RAM for a mail program seems ridiculous to me, especially when mutt does just fine in under 5M. Additionally, I could never configure kmail's key bindings to be what I like (surely my failure there).

So I created a new .muttrc file to hold all the info about my IMAP mailboxes at work. A simple mutt -F work.muttrc starts up an instance to access my work accounts (I found this more suitable than using account-hook configurations). mutt works like a charm and handles S/MIME attachments even better than kmail does.

But, I couldn't figure out a way for mutt to execute an arbitrary shell script when it finds that I have new mail in my box. It turns out that despite all of mutt's useful hooks and configuration, it is not able to do what I want. From the ridiculous and impolite comments on this thread it seems the behavior is a design decision not an oversight.

I wasn't about to go back to using kmail after having mutt set up so nicely. So, here's a patch that adds the functionality to mutt. The patch is against mutt version 1.5.10i and adds the configuration variable new_mail_notify. Set the variable to the path of a shell script and it will be run as soon as mutt notices that you have new mail in the current folder. The patch is a bit rough, but it's worked for me for about a week now.

Apple simplicity

As I've experimented with my new iBook, I've come to the conclusion that Apple's design philosophy stems heavily from an emphasis on simplicity. A good example is the safe sleep feature found on the newer PowerBooks. Instead of offering separate hibernate and sleep modes like Windows and Linux do, Apple offers one mode which transforms into the other mode as necessary. Essentially, I don't want my computer to "sleep" or to "hibernate" I want it to stay where I was until I come back for it. If that's 5 minutes or 5 days, the computer should still do what I want. I shouldn't have to decide in advance how long I'll be gone.

Another example of the simplicity is the single button mouse. I disagree with this simplication since I efficiently use all three mouse buttons on my Linux machines (when I can't do it from the keyboard that is). Nevertheless, it seems that Apple determined that it was possible to get by with only one mouse button so they did (at least, until recently).

The layout of application screens is a third demonstration of simplicity in OS X. This article about KDE learning from OS X makes some interesting suggestions, particularly, points two and three about simple toolbars. There is no need for a program to display 30 icons for features that one rarely uses (talk about iconic sprawl). True, one can customize the toolbars in most operating systems, but one shouldn't have to reclaim real estate from the toolbar monster.

Apple reminds me of our new house shortly after we moved in. The previous owners had filled the house with all manner of clutter. When they moved, we removed all the clutter they left behind. We put infrequently-used items in closets. Anything we use less than monthly, we moved to the storage shed. Anything we use less than yearly, we donated or threw away. When the previous owners came by to visit, they commented on how much we had done with the place. Of course, we hadn't changed anything but throw out the superfluous junk. Apple seems to have applied the same principle to software design.

All this reminds me of the design philosophy behind 37 Signals: "Our products do less than the competition — intentionally." Or perhaps the philosophy of Unix utilities: "do few things and do them well." Overall, it's been a reminder to me to balance simplicity and functionality in my software design. At some level, all good solutions are simple and naturally apply themselves beyond the original problem domain.

Color in mutt from DarwinPorts is broken

Last night, I installed mutt-devel 1.5.11 from DarwinPorts. It worked wonderfully, but the colors didn't work. All I saw was black and white. I tried everything I could think of (yes, .muttrc had "color" directives). I tried to troubleshoot the problem through the archives of various mailing lists, but they offered no hints. I checked mutt -v to make sure that color was enabled. Sure enough, +HAVE_COLOR +HAVE_START_COLOR were in the list. Still, mutt color was broken.

This was my first attempt to get anything from DarwinPorts to work on Mac OS X, so I was a bit oblivious. As I further diagnosed the problem, I got annoyed that OS X vim also showed no colors. On top of that, ls -G showed no colors. Hmm, I see a trend.

Here's the history behind the problem. Last night as I was getting mutt to work on my shiny new iBook, I noticed that colors disappeared when I ssh'd into my desktop or home server. Both of those machines run Debian testing ("etch"). In my .bashrc on those two machines, I examine $TERM before setting the colors. I only accepted "rxvt" and "xterm" but OS X Terminal sets TERM to "xterm-color". I said to myself, "Self, just tell Terminal to identify itself as 'xterm' and colors will then work on your Debian machines." I listened to myself, made the change and the colors worked. What I didn't notice at that late hour was that they also broke everywhere else.

So, to get mutt and ls and vim to show colors again, I just told Terminal to identify itself as 'xterm-color' again and everything worked. To get my Debian machines working again, I simply added 'xterm-color' to the list of acceptable terminal types.

The moral of the story is: change settings in the system you know best.

I hate software ... Yeah! for software

Yesterday, I noticed that debian testing ("etch") had upgraded KDE to version 3.4. Naturally, I apt-get update; apt-get upgrade and proceeded to get all the shiny new KDE toys along with a bunch of other updates. After restarting KDE, my sound is broken. I spent too much time this morning trying to get it working and it doesn't. Certainly, this is a result of my own ineptitude, but still, software is dumb.

A few minutes later, I was fooling with DCOP so that I could get the konversation IRC client to jump out of my system tray and show itself when I do Ctl+Alt+K. dcop konversation main_window show did the trick. A few minutes later, I had created a simple keyboard shortcut with KHotKeys which runs that cute little DCOP command to do exactly what I want (KHotKeys >> New Action >> Keyboard Shortcut - DCOP Call and then set the appropriate "DCOP Call Settings". Software is cool.

I get my new iBook this afternoon. Hopefully software will still be cool then.