[Openswan Users] Openswan 2.4.4 on FC5 against OpenBSD 4.0 isakmpd server
Albert Chin
openswan-users at mlists.thewrittenword.com
Wed Nov 22 03:03:33 EST 2006
I'm trying to get an FC5 laptop behind a firewall connected to an
OpenBSD 4.0 server running isakmpd (controlled by ipsecctl) with IPsec
using CA authentication. The CA authentication seems to be working and
I seem to have passed the Phase 1 exchange but am getting stuck in the
Phase 2 exchange. According to the OpenBSD ipsec.conf(5) man page:
main auth algorithm enc algorithm group group
These parameters define the cryptographic transforms to be used for
main mode. Possible values for auth, enc, and group are described
below in CRYPTO TRANSFORMS.
If omitted, ipsecctl(8) will use the default values hmac-sha1, aes,
and modp1024.
quick auth algorithm enc algorithm group group
These parameters define the cryptographic transforms to be used for
quick mode. Possible values for auth, enc, and group are described
below in CRYPTO TRANSFORMS. If group is specified, Perfect Forward
Security (PFS) is used. If the value none is used, PFS is dis-
abled.
If omitted, ipsecctl(8) will use the default values hmac-sha2-256
and aes; PFS will only be used if the remote side requests it.
My /etc/ipsec.d/work.conf:
conn work
type=tunnel
left=[ip of eth0 on FC5 laptop]
right=[vpn server ip]
keyexchange=ike
auto=ignore
auth=esp
ike=aes128-sha1-modp1024
esp=3des-sha1-96
authby=rsasig
leftrsasigkey=%cert
leftid=@[FC5 laptop]
leftcert=[FC5 laptop].crt
leftsendcert=always
rightrsasigkey=%cert
rightid=@[vpn host]
rightcert=[vpn host].crt
# ipsec auto --replace work; ipsec auto --up --verbose work
002 "work" #13: initiating Main Mode
104 "work" #13: STATE_MAIN_I1: initiate
003 "work" #13: ignoring unknown Vendor ID payload [6c0dcd481deae8ae0b0a68384b3072f9]
003 "work" #13: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
003 "work" #13: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] method set to=108
003 "work" #13: received Vendor ID payload [RFC 3947] method set to=109
003 "work" #13: received Vendor ID payload [Dead Peer Detection]
002 "work" #13: enabling possible NAT-traversal with method 3
002 "work" #13: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
106 "work" #13: STATE_MAIN_I2: sent MI2, expecting MR2
003 "work" #13: NAT-Traversal: Result using 3: i am NATed
002 "work" #13: I am sending my cert
002 "work" #13: I am sending a certificate request
002 "work" #13: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
108 "work" #13: STATE_MAIN_I3: sent MI3, expecting MR3
003 "work" #13: ignoring informational payload, type IPSEC_INITIAL_CONTACT
002 "work" #13: Main mode peer ID is ID_FQDN: '@[vpn host]'
002 "work" #13: no crl from issuer "[blah]" found (strict=no)
002 "work" #13: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
004 "work" #13: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=aes_128 prf=oakley_sha group=modp1024}
002 "work" #14: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP {using isakmp#13}
117 "work" #14: STATE_QUICK_I1: initiate
010 "work" #14: STATE_QUICK_I1: retransmission; will wait 20s for response
010 "work" #14: STATE_QUICK_I1: retransmission; will wait 40s for response
031 "work" #14: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
000 "work" #14: starting keying attempt 2 of an unlimited number, but releasing whack
I had to set ike=aes128-sha1-modp1024 to get the Phase 1 exchange
working. I'm thinking the esp setting is the cause for the hangup on
Phase 2. With no esp setting, I have the same problem.
A tcpdump on the OpenBSD packet filter log interface returns:
payload: VENDOR len: 20 (supports DPD v1.0) (ttl 64, id 49708, len 212)
Nov 22 01:55:21.050995 rule 18/(match) [uid 0, pid 5127] pass in on fxp4: [firewall].isakmp > [vpn host].isakmp: [udp sum ok] isakmp v1.0 exchange ID_PROT
cookie: 410317374a2bc3e7->8de62bef04821132 msgid: 00000000 len: 228
payload: KEY_EXCH len: 132
payload: NONCE len: 20
payload: NAT-D len: 24
payload: NAT-D len: 24 (DF) (ttl 55, id 0, len 256)
Nov 22 01:55:21.068648 rule 20/(match) [uid 0, pid 5127] pass out on fxp4: [vpn host].isakmp > [firewall].isakmp: [udp sum ok] isakmp v1.0 exchange ID_PROT
cookie: 410317374a2bc3e7->8de62bef04821132 msgid: 00000000 len: 228
payload: KEY_EXCH len: 132
payload: NONCE len: 20
payload: NAT-D len: 24
payload: NAT-D len: 24 (ttl 64, id 42348, len 256)
I can specify the following for the auth/enc keywords on OpenBSD:
The following authentication types are permitted with the auth keyword:
Authentication Key Length
hmac-md5 128 bits
hmac-ripemd160 160 bits [quick mode only]
hmac-sha1 160 bits
hmac-sha2-256 256 bits
hmac-sha2-384 384 bits
hmac-sha2-512 512 bits
The following cipher types are permitted with the enc keyword:
Cipher Key Length
des 56 bits
3des 168 bits
aes 128 bits
aesctr 160 bits [quick mode only]
blowfish 160 bits
cast 128 bits
skipjack 80 bits
According to ipsec_spi, the --esp parameter takes the following:
--esp add an SA for an IPSEC Encapsulation Security Payload, speci-
fied by the following transform identifier (3des, or 3des-
md5-96) (RFC2406, obsoletes RFC1827)
3des encryption transform following the Triple-DES standard in
Cipher-Block-Chaining mode using a 64-bit iv (internally gen-
erated) and a 192-bit 3DES ekey (RFC2451)
3des-md5-96
encryption transform following the Triple-DES standard in
Cipher-Block-Chaining mode with authentication provided by
HMAC and MD5 (96-bit authenticator), using a 64-bit iv
(internally generated), a 192-bit 3DES ekey and a 128-bit
HMAC-MD5 akey (RFC2451, RFC2403)
3des-sha1-96
encryption transform following the Triple-DES standard in
Cipher-Block-Chaining mode with authentication provided by
HMAC and SHA1 (96-bit authenticator), using a 64-bit iv
(internally generated), a 192-bit 3DES ekey and a 160-bit
HMAC-SHA1 akey (RFC2451, RFC2404)
If setting esp is the solution to my Phase 2 exchange problem, what do
I set it to?
--
albert chin (china at thewrittenword.com)
More information about the Users
mailing list