On 11/9/06, jared r r spiegel <[EMAIL PROTECTED]> wrote: > > On Wed, Nov 08, 2006 at 07:50:46AM +1100, nuffnough wrote: > > I have an OpenBSD 3.9 box and I've been asked to configure it to > terminate a > > VPN using AES-256 encryption with SHA authentication, DH Group 5 (rather > > than the default group 2) and a lifetime of one day. I configured my > > isakmpd.conf file like this: > > if you've any interest in trying to use ipsecctl, and if you have other > machines on 4.0 or -current, i was entirely 100% successful ( 'was' as > now the 3.9 boxes this applied to are 4.0 ) with using ipsecctl from > a late -current on 3.9 machines.
Upgrades will go ahead over the coming weekend. My disks finally arrived! (It is a bummer living in asia sometimes. Everything goes slower) the ipsecctl in 3.9-REL was a bit less robust in what it understood in the > config file, compared to 4.0. > > at worst, you could run it with lots of -v and then eyeball the FIFO > commands > it does and then write up an isakmpd.conf around that. > > but ipsecctl aside: > > > ** > > [Phase 1] > > Default= ISAKMP-peer-default > > 10.1.2.138= ISAKMP-peer-xx > > > > [Phase 2] > > Connections= IPsec-xx1-rl1-2, IPsec-xx1-rl1-3 > > > > [ISAKMP-peer-xx] > <...> > > [IPsec-xx1-rl1-2] > > Phase= 2 > > ISAKMP-peer= ISAKMP-peer-xx > > is -bp == -xx ? Yes. Sorry about that. > What ended up happening was that my end was initiating the tunnel using > > AES-128, and a lifetime of 1 hour (the default configuration as > indicated > > in the man page). > > > I defined my own Transform ... > <...> > > My understanding from reading the man page is that is the syntax I need > to > > use. It also means that we should be attempting to send a 256 bit key > > length with a lifetime of 1 day (86400 seconds) whenever we're > initiating > > the tunnel. Also, MODP_1536 should be correct for DH Group 5. Please > let > > me know if I am wrong here. > > yup, 1536 is 5 Thanks for the confirmation. if it helps diagnose stuff for you, this doesn't catch _everything_, but > it helped me a great deal with filtering out too much verboseness in the > majority of my debug fricking with isakmpd: > > $ sudo /sbin/isakmpd -dDA=0 -D2=50 -D5=50 -D7=50 -D8=40 -D9=30 awesome. I've just being using -DA=99 and getting lost. :-) > What actually happened was that my box stopped trying to initiate the > > tunnel. With the old configuration I was getting a packet exchange > every > > couple of minutes. > > was that perhaps because it was always unsuccessful and was just > retrying?, When I say stopped making any attempt, perhaps I should have been clearer. Prior to the change I was seeing two ipsec packets every two minutes. I forget what they were now. After I made the change, I saw none. This was using tcpdump -netttl -i rl0 | grep 10.1.2.138 or did everything get established and you made it out the other side of > phase-2 OK, but the actual parameters used were simply not the ones > desired? No Phase one. Just a packet to initiate, then a packet back to say that the far end doesn't like me. Debug on the other end indicated that when my end initiates, it does it with 128bit key length and a lifetime of one hour. Of course, I didn't have the brilliant idea of just setting my end up as passive, to make sure that the other end initiates. The required parameters fall within the ranges of the default AES-SHA config. after they go through phase-1 and make it through phase-2, they ( the > isakmpd processes, or at least your isakmpd and whatever the other side > is ) > should be /relatively/ quiet. Yep. Also, typically once phase-1 is established, phase-2 problems are relatively trivial. And mostly just problems with my policy file. > After I made this change all my other VPNs came up as > > usual but there was no traffic at all relating to this tunnel. > > > > Is my syntax incorrect? > > without running it through isakmpd to parse it, and given that i'm a bit > rusty with isakmpd.conf, nothing jumps out at me. The real (prolly newbie) question that I think I need the answer to is: After I define a custom transform, am I still able to call the standard pre-defined transforms at the same time? I can't see a problem with it, but then I don't (presently) understand how the system loads these definitions. I have about 20 other vpns with diverse encryption parameters. It would be moderately painful if I had to manually configure them all just to make this new one work. > Is there something I am missing about the structure of isakmpd.conf about > > the placement or reference of these new sections for lifetime and > > XX-AES-SHA? > > tbh i don't recall if order matters. here's a c/p of an isakmpd.conf > w/"custom" phase-1 and phase-2 i had running stable up until i switched > over to an ipsecctl-based scheme. ( we had our own X509 fqdn certs > from back in the certpatch days ). either end of the tunnel was OK > to initiate the negotiation, and the intent was for the tunnels to be > always up. Was this the only definition in your isakmpd.conf at the time..? > > > > If not, can you show me what I am doign wrong, so that I can > > do it right? > > regarding: "other VPNs came up fine, but no traffic relating > to this tunnel" -- does that mean you didn't see anything about > this in, say, 'netstat -rnf encap', ?, or that you did see the > flow established but nothing happened to be working across it?. There was absolutely no traffic logged in tcpdump. Also netstat -rnf encap showed all my usual vpns, but not this new one. Just at the moment the guy configuring the other end has stepped it down to 128bit with a 1 hour timeout for me and we now get Phase-1 okay. This is a little unfortunate, because it means I can't run any of these ipsecadm/ipsecctl tests to get the output to give you so you can help me. I expect that he'll be back on deck in a few hours, and I will dump it in here then. Thanks heaps for the great response. I will get the DA debug info here ASAP. nuffi
