[Openswan Users] *Solved* CentOS IPsec RSA sigs
Bao Wang
baowang98 at yahoo.com
Thu Mar 10 12:28:24 EST 2011
It looks like that EVENT_SO_DISCARD deleted the state with cookies from both endpoints before the SA_AUTH. So I will include the whole log content here and hope it will help.
Any idea how to fix this problem ?
Mar 10 09:20:00 localhost pluto[12953]: | *received 836 bytes from IP_2:500 on eth0 (port=500)
Mar 10 09:20:00 localhost pluto[12953]: | **parse ISAKMP Message:
Mar 10 09:20:00 localhost pluto[12953]: | initiator cookie:
Mar 10 09:20:00 localhost pluto[12953]: | 52 ab 2a b1 59 51 07 89
Mar 10 09:20:00 localhost pluto[12953]: | responder cookie:
Mar 10 09:20:00 localhost pluto[12953]: | 00 00 00 00 00 00 00 00
Mar 10 09:20:00 localhost pluto[12953]: | next payload type: ISAKMP_NEXT_v2SA
Mar 10 09:20:00 localhost pluto[12953]: | ISAKMP version: IKEv2 version 2.0 (rfc4306)
Mar 10 09:20:00 localhost pluto[12953]: | exchange type: ISAKMP_v2_SA_INIT
Mar 10 09:20:00 localhost pluto[12953]: | flags: ISAKMP_FLAG_INIT
Mar 10 09:20:00 localhost pluto[12953]: | message ID: 00 00 00 00
Mar 10 09:20:00 localhost pluto[12953]: | length: 836
Mar 10 09:20:00 localhost pluto[12953]: | processing version=2.0 packet with exchange type=ISAKMP_v2_SA_INIT (34)
Mar 10 09:20:00 localhost pluto[12953]: | ICOOKIE: 52 ab 2a b1 59 51 07 89
Mar 10 09:20:00 localhost pluto[12953]: | RCOOKIE: 00 00 00 00 00 00 00 00
Mar 10 09:20:00 localhost pluto[12953]: | state hash entry 10
Mar 10 09:20:00 localhost pluto[12953]: | v2 state object not found
Mar 10 09:20:00 localhost pluto[12953]: | ICOOKIE: 52 ab 2a b1 59 51 07 89
Mar 10 09:20:00 localhost pluto[12953]: | RCOOKIE: 00 00 00 00 00 00 00 00
Mar 10 09:20:00 localhost pluto[12953]: | state hash entry 10
Mar 10 09:20:00 localhost pluto[12953]: | v2 state object not found
Mar 10 09:20:00 localhost pluto[12953]: | ***parse IKEv2 Security Association Payload:
Mar 10 09:20:00 localhost pluto[12953]: | next payload type: ISAKMP_NEXT_v2KE
Mar 10 09:20:00 localhost pluto[12953]: | critical bit: Payload-Critical
Mar 10 09:20:00 localhost pluto[12953]: | length: 508
Mar 10 09:20:00 localhost pluto[12953]: | processing payload: ISAKMP_NEXT_v2SA (len=508)
Mar 10 09:20:00 localhost pluto[12953]: | ***parse IKEv2 Key Exchange Payload:
Mar 10 09:20:00 localhost pluto[12953]: | next payload type: ISAKMP_NEXT_v2Ni
Mar 10 09:20:00 localhost pluto[12953]: | length: 264
Mar 10 09:20:00 localhost pluto[12953]: | transform type: 14
Mar 10 09:20:00 localhost pluto[12953]: | processing payload: ISAKMP_NEXT_v2KE (len=264)
Mar 10 09:20:00 localhost pluto[12953]: | ***parse IKEv2 Nonce Payload:
Mar 10 09:20:00 localhost pluto[12953]: | next payload type: ISAKMP_NEXT_v2V
Mar 10 09:20:00 localhost pluto[12953]: | critical bit: Payload-Critical
Mar 10 09:20:00 localhost pluto[12953]: | length: 20
Mar 10 09:20:00 localhost pluto[12953]: | processing payload: ISAKMP_NEXT_v2Ni (len=20)
Mar 10 09:20:00 localhost pluto[12953]: | ***parse IKEv2 Vendor ID Payload:
Mar 10 09:20:00 localhost pluto[12953]: | next payload type: ISAKMP_NEXT_NONE
Mar 10 09:20:00 localhost pluto[12953]: | critical bit: Payload-Non-Critical
Mar 10 09:20:00 localhost pluto[12953]: | length: 16
Mar 10 09:20:00 localhost pluto[12953]: | processing payload: ISAKMP_NEXT_v2V (len=16)
Mar 10 09:20:00 localhost pluto[12953]: | found connection: test
Mar 10 09:20:00 localhost pluto[12953]: | creating state object #1 at 0x816a610
Mar 10 09:20:00 localhost pluto[12953]: | processing connection test
Mar 10 09:20:00 localhost pluto[12953]: | ICOOKIE: 52 ab 2a b1 59 51 07 89
Mar 10 09:20:00 localhost pluto[12953]: | RCOOKIE: 00 00 00 00 00 00 00 00
Mar 10 09:20:00 localhost pluto[12953]: | state hash entry 10
Mar 10 09:20:00 localhost pluto[12953]: | inserting state object #1 on chain 10
Mar 10 09:20:01 localhost pluto[12953]: | inserting event EVENT_SO_DISCARD, timeout in 0 seconds for #1
Mar 10 09:20:01 localhost pluto[12953]: | processing connection test
Mar 10 09:20:01 localhost pluto[12953]: | helper -1 doing build_kenonce op id: 37
Mar 10 09:20:01 localhost pluto[12953]: packet from IP_2:500: pluto_do_crypto: helper (-1) is exiting
Mar 10 09:20:01 localhost pluto[12953]: | processing connection test
Mar 10 09:20:01 localhost pluto[12953]: | ****parse IKEv2 Proposal Substructure Payload:
Mar 10 09:20:01 localhost pluto[12953]: | next payload type: ISAKMP_NEXT_P
Mar 10 09:20:01 localhost pluto[12953]: | length: 44
Mar 10 09:20:01 localhost pluto[12953]: | prop #: 1
Mar 10 09:20:01 localhost pluto[12953]: | proto ID: 1
Mar 10 09:20:01 localhost pluto[12953]: | spi size: 0
Mar 10 09:20:01 localhost pluto[12953]: | # transforms: 4
Mar 10 09:20:01 localhost pluto[12953]: | *****parse IKEv2 Transform Substructure Payload:
Mar 10 09:20:01 localhost pluto[12953]: | next payload type: ISAKMP_NEXT_T
Mar 10 09:20:01 localhost pluto[12953]: | length: 12
Mar 10 09:20:01 localhost pluto[12953]: | transform type: 1
Mar 10 09:20:01 localhost pluto[12953]: | transform ID: 12
Mar 10 09:20:01 localhost pluto[12953]: | ******parse IKEv2 Attribute Substructure Payload:
Mar 10 09:20:01 localhost pluto[12953]: | af+type: KEY_LENGTH
Mar 10 09:20:01 localhost pluto[12953]: | length/value: 128
Mar 10 09:20:01 localhost pluto[12953]: | *****parse IKEv2 Transform Substructure Payload:
Mar 10 09:20:01 localhost pluto[12953]: | next payload type: ISAKMP_NEXT_T
Mar 10 09:20:01 localhost pluto[12953]: | length: 8
Mar 10 09:20:01 localhost pluto[12953]: | transform type: 3
Mar 10 09:20:01 localhost pluto[12953]: | transform ID: 2
Mar 10 09:20:01 localhost pluto[12953]: | *****parse IKEv2 Transform Substructure Payload:
Mar 10 09:20:01 localhost pluto[12953]: | next payload type: ISAKMP_NEXT_T
Mar 10 09:20:01 localhost pluto[12953]: | length: 8
Mar 10 09:20:01 localhost pluto[12953]: | transform type: 2
Mar 10 09:20:01 localhost pluto[12953]: | transform ID: 2
Mar 10 09:20:01 localhost pluto[12953]: | *****parse IKEv2 Transform Substructure Payload:
Mar 10 09:20:01 localhost pluto[12953]: | next payload type: ISAKMP_NEXT_NONE
Mar 10 09:20:01 localhost pluto[12953]: | length: 8
Mar 10 09:20:01 localhost pluto[12953]: | transform type: 4
Mar 10 09:20:01 localhost pluto[12953]: | transform ID: 14
Mar 10 09:20:01 localhost pluto[12953]: | ****parse IKEv2 Proposal Substructure Payload:
Mar 10 09:20:01 localhost pluto[12953]: | next payload type: ISAKMP_NEXT_P
Mar 10 09:20:01 localhost pluto[12953]: | length: 44
Mar 10 09:20:01 localhost pluto[12953]: | prop #: 2
Mar 10 09:20:01 localhost pluto[12953]: | proto ID: 1
Mar 10 09:20:01 localhost pluto[12953]: | spi size: 0
Mar 10 09:20:01 localhost pluto[12953]: | # transforms: 4
Mar 10 09:20:01 localhost pluto[12953]: | complete v2 state transition with STF_OK
Mar 10 09:20:01 localhost pluto[12953]: "test" #1: transition from state STATE_IKEv2_START to state STATE_PARENT_R1
Mar 10 09:20:01 localhost pluto[12953]: "test" #1: STATE_PARENT_R1: received v2I1, sent v2R1 {auth=IKEv2 cipher=aes_128 integ=sha1 prf=oakley_sha group=modp2048}
Mar 10 09:20:01 localhost pluto[12953]: | sending reply packet to IP_2:500 (from port 500)
Mar 10 09:20:01 localhost pluto[12953]: | sending 376 bytes for STATE_IKEv2_START through eth0:500 to IP_2:500 (using #1)
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 IP_2: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 IP_2:500: sending notification v2N_INVALID_MESSAGE_ID to IP_2: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
Mar 10 09:20:11 localhost pluto[12953]: |
Mar 10 09:20:11 localhost pluto[12953]: | *received 316 bytes from IP_2:500 on eth0 (port=500)
Mar 10 09:20:11 localhost pluto[12953]: | **parse ISAKMP Message:
Mar 10 09:20:11 localhost pluto[12953]: | initiator cookie:
Mar 10 09:20:11 localhost pluto[12953]: | 52 ab 2a b1 59 51 07 89
Mar 10 09:20:11 localhost pluto[12953]: | responder cookie:
Mar 10 09:20:11 localhost pluto[12953]: | a5 6b 87 cd 39 8a a5 ed
Mar 10 09:20:11 localhost pluto[12953]: | next payload type: ISAKMP_NEXT_v2E
Mar 10 09:20:11 localhost pluto[12953]: | ISAKMP version: IKEv2 version 2.0 (rfc4306)
Mar 10 09:20:11 localhost pluto[12953]: | exchange type: ISAKMP_v2_AUTH
Mar 10 09:20:11 localhost pluto[12953]: | flags: ISAKMP_FLAG_INIT
Mar 10 09:20:11 localhost pluto[12953]: | message ID: 00 00 00 01
Mar 10 09:20:11 localhost pluto[12953]: | length: 316
Mar 10 09:20:11 localhost pluto[12953]: | processing version=2.0 packet with exchange type=ISAKMP_v2_AUTH (35)
Mar 10 09:20:11 localhost pluto[12953]: | ICOOKIE: 52 ab 2a b1 59 51 07 89
Mar 10 09:20:11 localhost pluto[12953]: | RCOOKIE: a5 6b 87 cd 39 8a a5 ed
Mar 10 09:20:11 localhost pluto[12953]: | state hash entry 15
Mar 10 09:20:11 localhost pluto[12953]: | v2 state object not found
Mar 10 09:20:11 localhost pluto[12953]: | ICOOKIE: 52 ab 2a b1 59 51 07 89
Mar 10 09:20:11 localhost pluto[12953]: | RCOOKIE: 00 00 00 00 00 00 00 00
Mar 10 09:20:11 localhost pluto[12953]: | state hash entry 10
Mar 10 09:20:11 localhost pluto[12953]: | v2 state object not found
Mar 10 09:20:11 localhost pluto[12953]: packet from IP_2:500: sending notification v2N_INVALID_MESSAGE_ID to IP_2:500
Mar 10 09:20:11 localhost pluto[12953]: | * processed 0 messages from cryptographic helpers
Mar 10 09:20:11 localhost pluto[12953]: | next event EVENT_PENDING_PHASE2 in 69 seconds
Mar 10 09:20:11 localhost pluto[12953]: | next event EVENT_PENDING_PHASE2 in 69 seconds
Mar 10 09:20:31 localhost pluto[12953]: |
--- On Thu, 3/10/11, Bao Wang <baowang98 at yahoo.com> wrote:
> From: Bao Wang <baowang98 at yahoo.com>
> Subject: Re: [Openswan Users] *Solved* CentOS IPsec RSA sigs
> To: "SilverTip257" <silvertip257 at gmail.com>
> Cc: "Openswan Users" <users at openswan.org>
> Date: Thursday, March 10, 2011, 9:40 AM
> 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
> > >>
> > >
> > >
> > >
> > >
> >
>
>
>
> _______________________________________________
> 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