I've finally got IPsec working between Data OnTap 6.4.5 and Solaris 10 systems! I can finally feel more comfortable running NFS to clients in public labs with accessable network jacks. It also works with RHEL, and OS X.
It turns out that a simple ascii to hex translation does work. (For Linux and MacOS X, just use the same ascii as the psk.txt file.) My problem was that I was trying to use Solaris 8, which doesn't have IKE support. The NetApp IPsec docs don't make it clear that IKE is required, and I was confusing manually keyed SAs with shared keys for IKE. IKE is used to generate keys to be used with the SAs (Security Associations). Manually keyed SAs don't use IKE at all, and apparently aren't supported in Data OnTap 6.4.5, (and are less secure without some means for regular and frequent replacement).
I ran some basic timing tests from
http://www.connectathon.org/nfstests.html
both with and without IPsec (just ah (Athentication Headers), not esp (Encapsulation Security Payload)), and the performance hit seems minimal. I have yet to run tests on more than a single system at a time. I'm guessing we'll want to purchase the accelerator card, but haven't researched the pricing yet.
I haven't yet figured out exactly which combinations of the various policy specifications don't work, but here's what we used that works: Loosely based on the directions at:
http://docs.sun.com/app/docs/doc/816-4554/6maoq0219?a=view
Filer host: filer.ucsd.edu 192.168.13.100 NFS client host: Sol10-nfs-client.ucsd.edu 192.168.13.200
Files on Sol10-nfs-client.ucsd.edu:
/etc/inet/ipsecinit.conf:
{laddr 192.168.13.200 raddr 192.168.13.100} ipsec {auth_algs md5 sa shared}
/etc/inet/ike/config:
...perhaps other preceding stuff... { label "sol10nfsclient-filer" local_addr 192.168.13.200 remote_addr 192.168.13.100 p1_xform { auth_method preshared oakley_group 1 auth_alg md5 encr_alg des } p2_pfs 2 }
We're suspicious that the oakley_group needs to be '1', and that the p2_pfs number must be '2', or the filer won't be happy. It *may* even be the case that using different numbers will crash your filer. Perhaps related to:
Bug Number/Title: 85483 / SA delete all and subsequent reconnect from BSD client can panic filer
In our case, the filer crashed when a Linux client tried to set up an SA with a filer, and the Linux client was using oakley_group 5, (1536-bit) and a p2_pfs number of 5 (1536-bit).
/etc/inet/secret/ike.preshared:
... { localidtype IP localid 192.168.13.200 remoteidtype IP remoteid 192.168.13.100 key 6162636465666768696a6b6c6d6e6f70 }
Files on filer.ucsd.edu:
/etc/psk.txt:
192.168.13.100 abcdefghijklmnop
Now for some hopefully basic questions:
What is the limit on the number of entries in the psk.txt file? Are comments allowed in psk.tst file? What format are they?
Re:
From: Brian Parent bparent@calvin.ucsd.edu Date: Tue, 24 Aug 2004 14:35:56 -0700 Subject: Re: IPsec NFS to Unix clients To: toasters@mathworks.com
I just realized that the preshared keys for IPsec on a NetApp (as outlined in man na_psk.txt) are ascii, and on Solaris, (man ipseckey) they're in hex. Now, if I knew how NetApp's IPsec implementation translated their ascii string into bits, I could get the right corresponding hex representation to use on the Solaris client.
Anyone have any ideas?
I tried a simple a=0x61, b=0x62, so that abcd becomes 61626364, but that didn't work. I also tried swapping bytes so that abcd becomes 62616463, no luck there either. Of course it could be little endian vs. big endian, or swap words instead of bytes, or some combination of the above, or ...