[Openswan dev] Re: [Openswan Users] ike and esp proposals

Paul Wouters paul at xelerance.com
Thu Jan 5 16:43:00 CET 2006


On Thu, 5 Jan 2006, Matthias Haas wrote:

> but I have to insist, that the behavior you described is not reflected in the
> current snapshot 2.4.5rc1. The initiator forces to use 3des, but the
> responder only accepts aes. But still they aggree about using the proposal
> from the inititaot to use 3des.

> conn server_0-213.179.141.11_gw-gw_defaultroute-213.179.141.11
>         left=%defaultroute
>         right=213.179.141.11
>         type=tunnel
>         authby=rsasig
>         leftcert=/etc/ipsec.d/server.crt
>         leftsendcert=yes
>         auto=start
>         auth=esp
>         pfs=yes
>         ike=3des

Ok, you are forcing ike to use 3des. You are not setting/forcing esp=3des....

>         keylife=9h
>         keyingtries=0
>         ikelifetime=6h
>         disablearrivalcheck=no
>         rightid="/C=DE/CN=VPN-242"
>         rightrsasigkey=%cert

> "server_0-213.179.141.11_gw-gw_defaultroute-213.179.141.11" #1:
> STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG
> cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}

ike is using 3des as expected.

> Jan  5 09:32:25 vpn233 pluto[19901]:
> "server_0-213.179.141.11_gw-gw_defaultroute-213.179.141.11" #2:
> STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x72baecff <0x87a24255
> xfrm=AES_0-HMAC_SHA1 NATD=none DPD=none}

esp is using aes (as expected, it is the default and it is not forced to 3des)

> Settings and output from responder:

>         ike=aes

Ahh, this shows it should have failed to agree on an ike proposal....

> "server_0-adsl_gw-gw_213.179.141.11-0.0.0.0"[2] 84.155.253.155 #3:
> STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_RSA_SIG
> cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}

I guess this should not have been allowed.

> "server_0-adsl_gw-gw_213.179.141.11-0.0.0.0"[2] 84.155.253.155 #4:
> STATE_QUICK_R2: IPsec SA established {ESP=>0x87a24255 <0x72baecff
> xfrm=AES_0-HMAC_SHA1 NATD=none DPD=none}
>
> As you can see in phase 1 as they should not aggree about the proposals the
> responder accepts 3des as a valid proposal.

Indeed. I've filed a bug report:

http://bugs.xelerance.com/view.php?id=558

Paul


More information about the Dev mailing list