[Openswan Users] *Solved* CentOS IPsec RSA sigs
Bao Wang
baowang98 at yahoo.com
Thu Mar 10 10:40:18 EST 2011
Hi, Mike
Thank you for your response. I think I did everything as indicated in your email, but my ipsec had trouble to setup between two CentOs hosts.
I have to use ikev2 for this testing. Two hosts always get SA_INIT exchange done. Then they failed on SA_AUTH. The responder side always claimed "sending notification v2N_INVALID_MESSAGE_ID to xxx.xx.xx.xxx:500". Here is some part of log on the originator side. Then there will be more a lot of repeat of SA_AUTH from the originator and the responder would not send anything back. After some timeout, the whole sequence will start again.
Any idea what is wrong for this ?
Mar 10 09:20:01 localhost pluto[12953]: | complete v2 state transition with STF_INLINE
Mar 10 09:20:01 localhost pluto[12953]: | * processed 0 messages from cryptographic helpers
Mar 10 09:20:01 localhost pluto[12953]: | next event EVENT_SO_DISCARD in 0 seconds for #1
Mar 10 09:20:01 localhost pluto[12953]: | *time to handle event
Mar 10 09:20:01 localhost pluto[12953]: | handling event EVENT_SO_DISCARD
Mar 10 09:20:01 localhost pluto[12953]: | event after this is EVENT_PENDING_PHASE2 in 79 seconds
Mar 10 09:20:01 localhost pluto[12953]: | processing connection test
Mar 10 09:20:01 localhost pluto[12953]: | deleting state #1
Mar 10 09:20:01 localhost pluto[12953]: | ICOOKIE: 52 ab 2a b1 59 51 07 89
Mar 10 09:20:01 localhost pluto[12953]: | RCOOKIE: a5 6b 87 cd 39 8a a5 ed
Mar 10 09:20:01 localhost pluto[12953]: | state hash entry 15
Mar 10 09:20:01 localhost pluto[12953]: | ICOOKIE: 52 ab 2a b1 59 51 07 89
Mar 10 09:20:01 localhost pluto[12953]: | RCOOKIE: 00 00 00 00 00 00 00 00
Mar 10 09:20:01 localhost pluto[12953]: | state hash entry 10
Mar 10 09:20:01 localhost pluto[12953]: | next event EVENT_PENDING_PHASE2 in 79 seconds
Mar 10 09:20:01 localhost pluto[12953]: |
Mar 10 09:20:01 localhost pluto[12953]: | *received 316 bytes from 134.64.82.214:500 on eth0 (port=500)
Mar 10 09:20:01 localhost pluto[12953]: | **parse ISAKMP Message:
Mar 10 09:20:01 localhost pluto[12953]: | initiator cookie:
Mar 10 09:20:01 localhost pluto[12953]: | 52 ab 2a b1 59 51 07 89
Mar 10 09:20:01 localhost pluto[12953]: | responder cookie:
Mar 10 09:20:01 localhost pluto[12953]: | a5 6b 87 cd 39 8a a5 ed
Mar 10 09:20:01 localhost pluto[12953]: | next payload type: ISAKMP_NEXT_v2E
Mar 10 09:20:01 localhost pluto[12953]: | ISAKMP version: IKEv2 version 2.0 (rfc4306)
Mar 10 09:20:01 localhost pluto[12953]: | exchange type: ISAKMP_v2_AUTH
Mar 10 09:20:01 localhost pluto[12953]: | flags: ISAKMP_FLAG_INIT
Mar 10 09:20:01 localhost pluto[12953]: | message ID: 00 00 00 01
Mar 10 09:20:01 localhost pluto[12953]: | length: 316
Mar 10 09:20:01 localhost pluto[12953]: | processing version=2.0 packet with exchange type=ISAKMP_v2_AUTH (35)
Mar 10 09:20:01 localhost pluto[12953]: | ICOOKIE: 52 ab 2a b1 59 51 07 89
Mar 10 09:20:01 localhost pluto[12953]: | RCOOKIE: a5 6b 87 cd 39 8a a5 ed
Mar 10 09:20:01 localhost pluto[12953]: | state hash entry 15
Mar 10 09:20:01 localhost pluto[12953]: | v2 state object not found
Mar 10 09:20:01 localhost pluto[12953]: | ICOOKIE: 52 ab 2a b1 59 51 07 89
Mar 10 09:20:01 localhost pluto[12953]: | RCOOKIE: 00 00 00 00 00 00 00 00
Mar 10 09:20:01 localhost pluto[12953]: | state hash entry 10
Mar 10 09:20:01 localhost pluto[12953]: | v2 state object not found
Mar 10 09:20:01 localhost pluto[12953]: packet from ORIGINATOR_IP:500: sending notification v2N_INVALID_MESSAGE_ID to ORIGINAOR_IP:500
Mar 10 09:20:01 localhost pluto[12953]: | * processed 0 messages from cryptographic helpers
Mar 10 09:20:01 localhost pluto[12953]: | next event EVENT_PENDING_PHASE2 in 79 seconds
Mar 10 09:20:01 localhost pluto[12953]: | next event EVENT_PENDING_PHASE2 in 79 seconds
Best regards,
Bao
--- On Wed, 3/9/11, SilverTip257 <silvertip257 at gmail.com> wrote:
> From: SilverTip257 <silvertip257 at gmail.com>
> Subject: Re: [Openswan Users] *Solved* CentOS IPsec RSA sigs
> To: "Bao Wang" <baowang98 at yahoo.com>
> Cc: "Openswan Users" <users at openswan.org>
> Date: Wednesday, March 9, 2011, 10:41 AM
> Bao Wang,
>
> Please CC the Openswan Users list next time.
>
> *** Generating PSKs is nothing specific on CentOS/RHEL as
> compared to
> Debian or any other distro as far as I know.
>
> No, you do not need to change anything in /etc/ipsec.d/
> when using PSKs.
> You simply need to create a preshared key - preferably a
> lengthy
> random one. You could however just put a simple pass
> phrase in there,
> but that is not secure and not recommended! Consider
> switching to RSA
> sigs once you get a working setup with PSKs - since you're
> using
> Openswan-to-Openswan this won't be a problem.
>
> Use ipsec randbits.
> The SharedSecretsInProduction (link below) suggests at
> least 128 bit
> PSKs. This generates a 38 character PSK.
> debian507-vm:~# ipsec ranbits 128 > temp128
> debian507-vm:~# wc -m temp128
> 38 temp128
> [PSK gen suggestions]
> http://wiki.openswan.org/index.php/Openswan/UsingSharedSecretsInProduction
> -Note: There are other alternatives to create random
> strings, but
> randbits should suffice.
>
> Using the format for the ipsec.secrets file shown here:
> [see bottom] http://wiki.openswan.org/index.php/Openswan/ConfFiles
> ip1 ip2 : PSK "0xa449fd66_38b80c26_69337273..."
> You copy/paste (or cat the PSK into ipsec.secrets) and put
> in the proper format.
>
> Enough spoon feeding for today. I pieced together
> everything I have
> after much reading. And if it wasn't for the existing
> documentation I
> wouldn't have a working setup now. >> I'll consider
> contributing a
> more refined list to the wiki on secrets.
> Consider searching the wiki for information:
> http://wiki.openswan.org/index.php/Main/HomePage
> [example PSK] http://wiki.openswan.org/index.php/Main/SearchWiki?q=psk&action=search&submit_x=0&submit_y=0
> And search engines do a good job indexing the past emails
> sent to the
> Openswan Users mailing list.
>
> ---~~.~~---
> Mike
> // SilverTip257 //
>
>
>
> On Wed, Mar 9, 2011 at 10:12, Bao Wang <baowang98 at yahoo.com>
> wrote:
> > Hi,
> >
> > Will you mind to share your configuration for using
> PSK ? I simply tried to setup host-2-host ipsec with ikev2.
> The 2 hosts are running CentOs. Do you think that I also
> need regenerate ipsec.d for PSK ? Right now, my ipsec.conf
> looks like
> > "config setup
> > protostack=netkey
> > protostack=netkey
> > nat_traversal=no
> > oe=off
> > nhelpers=0
> >
> > conn test
> > auto=start
> > left=xxx.xx.xx.xxx (real ip address of host 1)
> > right=yyy.yy.yy.yy (real ip address of host 2)
> > ikev2=insist
> > keyingtries=5
> > rekeymargin=2m
> > authby=secret
> > pfs=yes
> > "
> > Your help will be greatly appreciated.
> >
> > Bao Wang
> >
> >
> > --- On Tue, 3/8/11, SilverTip257 <silvertip257 at gmail.com>
> wrote:
> >
> >> From: SilverTip257 <silvertip257 at gmail.com>
> >> Subject: [Openswan Users] *Solved* CentOS IPsec
> RSA sigs
> >> To: "Openswan Users" <users at openswan.org>
> >> Date: Tuesday, March 8, 2011, 8:58 PM
> >> I'm working on configuring my setup
> >> to use RSA signatures now that I
> >> have a working config using PSKs.
> >>
> >> I'm using CentOS5.4 as the left gateway and Debian
> Lenny as
> >> the right gateway.
> >> I had a bit of trouble generating keys until I
> used a
> >> different
> >> configdir as suggested here
> >> https://www.centos.org/modules/newbb/viewtopic.php?viewmode=thread&topic_id=22906&forum=38&post_id=105108
> >> [root at centos54vm ipsec.d]# ipsec newhostkey
> --output
> >> /etc/ipsec.secrets --configdir /etc/ipsec.d
> >> ipsec rsasigkey: key pair generation failed:
> "-8023"
> >> # Use NSSDB instead of ipsec.d
> >> [root at centos54vm ipsec.d]# ipsec newhostkey
> --output
> >> /etc/ipsec.secrets --configdir /etc/pki/nssdb
> >> Generated RSA key pair using the NSS database
> >>
> >> Now that I had an RSA sig in /etc/ipsec.secrets, I
> changed
> >> my ipsec.conf
> >> conn advc-d_rsa
> >> authby=rsasig
> >> auto=add
> >> left=192.168.110.2
> >> leftsourceip=172.16.0.33
> >> leftid=@centrsa
> >> leftrsasigkey=0sAQPT0eXk+...
> >> leftnexthop=192.168.110.1
> >> leftsubnet=172.16.0.32/27
> >> right=192.168.111.2
> >> rightsourceip=10.0.2.1
> >> rightsubnet=10.0.2.0/24
> >> rightid=@debrsa
> >> rightrsasigkey=0sAQODfpUObY...
> >>
> >> The hosts do not quickly change states and by
> checking the
> >> logs, I
> >> have noticed errors.
> >> * It most blatantly says that there's a problem
> with
> >> keys. However
> >> the key that the rightgw is trying is indeed the
> key for
> >> the leftgw.
> >>
> >> Mar 8 12:13:54 centos54vm pluto[8017]:
> "advc-d_rsa"
> >> #7: sending
> >> notification PAYLOAD_MALFORMED to
> 192.168.111.2:500
> >> Mar 8 12:13:57 centos54vm pluto[8017]:
> "advc-d_rsa"
> >> #6: discarding
> >> duplicate packet; already STATE_MAIN_I3
> >> Mar 8 12:14:04 centos54vm pluto[8017]:
> "advc-d_rsa"
> >> #6: ignoring
> >> informational payload, type
> INVALID_KEY_INFORMATION
> >> msgid=00000000
> >> Mar 8 12:14:04 centos54vm pluto[8017]:
> "advc-d_rsa"
> >> #6: received and
> >> ignored informational message
> >> Mar 8 12:14:07 centos54vm pluto[8017]:
> "advc-d_rsa"
> >> #6: discarding
> >> duplicate packet; already STATE_MAIN_I3
> >> Mar 8 12:14:24 centos54vm pluto[8017]:
> "advc-d_rsa"
> >> #6: ignoring
> >> informational payload, type
> INVALID_KEY_INFORMATION
> >> msgid=00000000
> >> Mar 8 12:14:24 centos54vm pluto[8017]:
> "advc-d_rsa"
> >> #6: received and
> >> ignored informational message
> >>
> >> Mar 8 12:58:04 centos54vm pluto[8566]: loaded
> private
> >> key for keyid:
> >> PPK_RSA:AQPT0eXk+
> >> 003 "advc-d_rsa" #4: Can't find the private key
> from the
> >> NSS CERT (err -12285)
> >> ---------
> >> Mar 8 19:58:44 debian507-vm pluto[3631]:
> "advc-d_rsa"
> >> #1: Main mode
> >> peer ID is ID_FQDN: '@centrsa'
> >> Mar 8 19:58:44 debian507-vm pluto[3631]:
> "advc-d_rsa"
> >> #1: Signature
> >> check (on @centrsa) failed (wrong key?); tried
> *AQPT0eXk+
> >> Mar 8 19:58:44 debian507-vm pluto[3631]:
> "advc-d_rsa"
> >> #1: sending
> >> encrypted notification INVALID_KEY_INFORMATION to
> >> 192.168.110.2:500
> >>
> >> *****
> >> SOLUTION:
> >> - For anyone running CentOS, it appears something
> is wrong
> >> with the
> >> /etc/ipsec.d/ NSS database files. So you'll have
> to
> >> regenerate new
> >> ones! Fixed my problem.
> >> *****
> >> cd /etc/ipsec.d/
> >> ls -l
> >> mkdir old
> >> # move the old NSS database to a folder named old;
> backup
> >> precaution.
> >> mv cert8.db key3.db secmod.db policies/ old/
> >> # I generated my new NSS cert without a password
> (leave it
> >> blank by
> >> pressing Enter), otherwise the --password flag is
> needed
> >> for
> >> generating the new RSA key.
> >> certutil -N -d /etc/ipsec.d
> >> # be careful not to overwrite your ipsec.secrets
> >> file! In this case
> >> we will append the RSA sig to secrets.
> >> ipsec newhostkey --output /etc/ipsec.rsa.secrets
> >> --configdir /etc/ipsec.d
> >> # if you want to time the command, prefix the
> command with
> >> `time`.
> >> #example: time ipsec newhostkey --output
> >> /etc/ipsec.rsa.secrets
> >> --configdir /etc/ipsec.d
> >> cat /etc/ipsec.rsa.secrets >>
> /etc/ipsec.secrets
> >>
> >> Make the proper @leftid/rightid changes to the
> RSA
> >> sig. Add the
> >> left/rightrsasigkey= line to your conn.
> >>
> >> ---~~.~~---
> >> Mike
> >> // SilverTip257 //
> >> _______________________________________________
> >> Users at openswan.org
> >> http://lists.openswan.org/mailman/listinfo/users
> >> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> >> Building and Integrating Virtual Private Networks
> with
> >> Openswan:
> >> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
> >>
> >
> >
> >
> >
>
More information about the Users
mailing list