[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