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. it seems to me that ipsecctl is just
a go-between to translate a configuration file into isakmpd FIFO commands,
who, apart from adding the 'passive only' ui_ command, don't look like
they've much changed in the past year.
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-bp
is -bp == -xx ?
> 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
$ awk '/^# IKE group/,/^\.$/ { print $0 }' /usr/src/sbin/isakmpd/ipsec_num.cst
# IKE group description.
IKE_GROUP_DESC
MODP_768 1
MODP_1024 2
EC2N_155 3
EC2N_185 4
MODP_1536 5
EC2N_163sect 6
EC2N_163K 7
EC2N_283sect 8
EC2N_283K 9
EC2N_409sect 10
EC2N_409K 11
EC2N_571sect 12
EC2N_571K 13
MODP_2048 14
MODP_3072 15
MODP_4096 16
MODP_6144 17
MODP_8192 18
.
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
> 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?,
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?
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.
> 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.
> 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.
---------
[general]
renegotiate-on-hup= please
default-phase-1-id= id1-self
# phase 1
[phase 1]
70.70.70.70= p1-peer1
[phase 2]
connections= p2-peer1
[id1-self]
id-type= fqdn
name= self.vpn
[id1-peer1]
id-type= fqdn
name= peer1.vpn
[p1-peer1]
phase= 1
address= 70.70.70.70
id= id1-self
remote-id= id1-peer1
configuration= p1cfg-vpn
# phase-2
[id2-self]
id-type= ipv4_addr
address= 172.16.7.30
[id2-peer1]
id-type= ipv4_addr
address= 172.16.196.1
[p2-peer1]
phase= 2
isakmp-peer= p1-peer1
local-id= id2-self
remote-id= id2-peer1
configuration= p2cfg-vpn
# xf/protocols
[2h]
life_type= seconds
life_duration= 7200
[p1cfg-vpn]
exchange_type= id_prot
transforms= p1cfg-vpn-xf
[p1cfg-vpn-xf]
authentication_method= rsa_sig
encryption_algorithm= aes_cbc
group_description= modp_2048
hash_algorithm= sha
key_length= 256
life= 2h
[p2cfg-vpn]
exchange_type= quick_mode
suites= p2cfg-vpn-suite
[p2cfg-vpn-suite]
protocols= p2cfg-vpn-proto
[p2cfg-vpn-proto]
protocol_id= ipsec_esp
transforms= p2cfg-vpn-xf
[p2cfg-vpn-xf]
authentication_algorithm= hmac_sha
encapsulation_mode= tunnel
group_description= modp_2048
transform_id= aes
key_length= 256
life= 2h
---------
> 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?.
if you still have ipsecadm (think it was still in 3.9), do
you get anything useful (regarding how far along the negotiations
progressed) out of 'ipsecadm show' ?. either that or 'ipsecctl -s blahblah'
in all my experiences with isakmpd ( to be fair, they're all,
except for one instance, with isakmpd on both ends ), if you
get through phase-1, and then get through phase-2, and get
flows established and managed, it is _up_, and the only thing
at that point is to get traffic into the tunnel, but as far
as isakmpd's part of the bargain goes, he's done and is on break.
tunnel might be up ok already?
--
jared
