[strongSwan] No acceptable DIFFIE_HELLMAN_GROUP found
William Greene
wgreene9617 at yahoo.com
Mon Nov 15 20:09:55 CET 2010
Andreas,
My apologies as my last email was incorrect. My test set up got blinkered some
how and the error TS_UNACCEPTABLE was well... incorrect.
I have fixed my set up and I'm back to getting "received NO_PROPOSAL_CHOSEN
notify, no CHILD_SA built", but it is now getting farther. Your previous
suggestion of using
"esp=aes256gcm16-modp1024-modp2048,aes128gcm16-modp1024-modp2048!" solved my "no
acceptable DIFFIE_HELLMAN_GROUP found". But still the ipsec connect eludes me.
On the mocana side I can see in the logs:
I -->
Notify: USE_TRANSPORT_MODE
TSi: 10.168.65.1 icmp
TSr: 10.168.80.8 icmp
spi={1f4d8f80069c25cf 6cfe69d01046128a} np=E{N}
exchange=CREATE_CHILD_SA msgid=1 len=396
SEND 396 bytes to 10.168.80.8[500] (2229.766)
RECV 348 bytes from 10.168.80.8[500] at 10.168.65.1 (2229.794)
spi={1f4d8f80069c25cf 6cfe69d01046128a} np=E{N}
exchange=CREATE_CHILD_SA msgid=1 len=348
I <--
Notify: USE_TRANSPORT_MODE
Proposal #1: ESP[3] spi=ca883928
ENCR_AES_GCM_16 256-BITS
DH_2
ESN_0
AUTH_ALG missing
CHILD_SA failed [v2 I], status = -8961
The mocana side is configured for gcm and sha256. I've tried inserting
"-sha256" to the esp line in Strongswan's ipsec.conf file and restarting ipsec.
No luck as sha265 never shows up in the proposals. I've tried setting both
sides to use sha1, but have the same negative result. The log from the
StrongSwan side:
Nov 15 13:48:18 05[CFG] received proposals:
ESP:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/HMAC_SHA1_96/MODP_1024/MODP_768/MODP_1536/MODP_2048/MODP_NONE/NO_EXT_SEQ
Nov 15 13:48:18 05[CFG] configured proposals:
ESP:AES_GCM_16_256/MODP_1024/MODP_2048/NO_EXT_SEQ
Nov 15 13:48:18 05[CFG] selected proposal:
ESP:AES_GCM_16_256/MODP_1024/NO_EXT_SEQ
If I set the mocana side for gcm and any, the ipsec connection comes up fine and
dandy. So obviously I must be misconfiguring the StrongSwan side? How do I
specify in the ipsec.conf file for the connection to use some version of sha,
preferably sha256?
Thanks again for all your help and patience,
Bill
________________________________
From: Andreas Steffen <andreas.steffen at strongswan.org>
To: William Greene <wgreene9617 at yahoo.com>
Cc: users at lists.strongswan.org
Sent: Mon, November 15, 2010 11:12:58 AM
Subject: Re: [strongSwan] No acceptable DIFFIE_HELLMAN_GROUP found
Hello Bill,
it seems that Mocana doesn't like the traffic selectors:
Notify: USE_TRANSPORT_MODE
TSi: 10.168.80.8
TSr: 10.168.65.1
Does Mocana support IPsec Transport Mode at all?
Try if type=tunnel works!
Regards
Andreas
On 11/15/2010 04:01 PM, William Greene wrote:
>
> Thank you Andreas for your quick reply. Your suggestion did do something
> as I'm getting a different error now: TS_UNACCEPTABLE. I've been unable
> to glean anything so far from the mailing list concerning this error and
> a host to host setup such as mine. I'm including some more log information.
>
> Thanks again in advance for comments or suggestions anyone may have.
>
>
>
> [root at KAP8 etc]# ipsec up testipsec
> initiating IKE_SA testipsec[3] to 10.168.65.1
> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
> sending packet: from 10.168.80.8[500] to 10.168.65.1[500]
> received packet: from 10.168.65.1[500] to 10.168.80.8[500]
> parsed IKE_SA_INIT response 0 [ N(COOKIE) ]
> initiating IKE_SA testipsec[3] to 10.168.65.1
> generating IKE_SA_INIT request 0 [ N(COOKIE) SA KE No N(NATD_S_IP)
> N(NATD_D_IP) ]
> sending packet: from 10.168.80.8[500] to 10.168.65.1[500]
> received packet: from 10.168.65.1[500] to 10.168.80.8[500]
> parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ ]
> received cert request for unknown ca with keyid
> 00:00:00:00:00:00:00:02:00:14:00:00:10:04:d9:b8:10:04:d9:b8
> authentication of '10.168.80.8' (myself) with pre-shared key
> establishing CHILD_SA testipsec
> generating IKE_AUTH request 1 [ IDi IDr AUTH N(USE_TRANSP) SA TSi TSr
> N(EAP_ONLY) ]
> sending packet: from 10.168.80.8[500] to 10.168.65.1[500]
> received packet: from 10.168.65.1[500] to 10.168.80.8[500]
> parsed IKE_AUTH response 1 [ IDr AUTH N(TS_UNACCEPT) ]
> authentication of '10.168.65.1' with pre-shared key successful
> IKE_SA testipsec[3] established between
> 10.168.80.8[10.168.80.8]...10.168.65.1[10.168.65.1]
> scheduling reauthentication in 3315s
> maximum IKE_SA lifetime 3495s
> received TS_UNACCEPTABLE notify, no CHILD_SA built
> [root at KAP8 etc]#
>
>
> From Mocana log:
>
> RECV 832 bytes from 10.168.80.8[500] at 10.168.65.1 (7376.217)
> spi={8562d7f0575052dd 0000000000000000} np=SA
> exchange=IKE_SA_INIT msgid=0 len=832
> <-- R
> Notify: COOKIE
> SEND 56 bytes to 10.168.80.8[500] (7376.226)
>
> RECV 860 bytes from 10.168.80.8[500] at 10.168.65.1 (7376.257)
> spi={8562d7f0575052dd 0000000000000000} np=N
> exchange=IKE_SA_INIT msgid=0 len=860
> --> R
> Notify: COOKIE
> Proposal #1: IKE[4]
> ENCR_AES 128-BITS
> AUTH_HMAC_SHA1_96
> PRF_HMAC_SHA1
> DH_14
>
> ==> ../Log/kern.log <==
> Nov 15 14:40:40 cep kernel: 0:ipsec_ioctl[638]: 0:cmd = 0x3eb, value =
> 0x040432000:
>
> ==> ../Log/nanosec-ike.log <==
> Notify: NAT_DETECTION_SOURCE_IP
> Notify: NAT_DETECTION_DESTINATION_IP
> SKEYSEED (20 bytes): 88aa0565daa02dff1febbbc10db446c589d3b0cb
> SK_d (20 bytes): 26d9261618cce7954e12fc0dce541570b9bbb918
> SK_ai (20 bytes): b86be01177a21425d8fc201a906af39f4f440ebf
> SK_ar (20 bytes): 0c439701fa8c24baa96702135e1a440df477066d
> SK_ei (16 bytes): a776670d396e0c025b53f22600bbd3a1
> SK_er (16 bytes): ac5e03572862a9b79fae695b5f908186
> SK_pi (20 bytes): 65f4333cfbf0dbff972b45f08cc67ff2dd0e1f9b
> SK_pr (20 bytes): 11d33c98f572ee0e700ddf72252dda67cd86913e
> <-- R
> NAT_D (us): 6c 9e 3c b8 79 6a a9 3e a5 51 9b 39 f6 96 0f fa
> 35 01 c5 53
> NAT_D (peer): d5 55 de cb 72 4c d6 42 b3 55 31 b1 af e6 b5 17
> 3e ea aa ec
> SEND 441 bytes to 10.168.80.8[500] (7379.93)
>
> RECV 252 bytes from 10.168.80.8[500] at 10.168.65.1 (7379.128)
> spi={8562d7f0575052dd 382c78998f61cd73} np=E{IDi}
> exchange=IKE_AUTH msgid=1 len=252
> --> R
> Notify: USE_TRANSPORT_MODE
> TSi: 10.168.80.8
> TSr: 10.168.65.1
> Notify: 16417
> prf(SK_pi,IDi') (20 bytes): 45ed7f17efa2d727ac3f0416ccd83493977c8676
> prf(SS,"*") (20 bytes): 6a3dc0ae9834bef9e35ebac3ac23f02f78c5f93b
> AUTH_i 91 19 66 53 b1 0e 98 5d 00 9b 56 c3 60 43 ba ff
> 99 79 d1 ff
> Proposal #1: ESP[2] spi=c9b5ce4d
> ENCR_AES_GCM_16 256-BITS
> ESN_0
> <-- R
> prf(SK_pr,IDr') (20 bytes): d1d6c3d9ee6e3273d0d4ab9580a7e2e0935840c6
> prf(SS,"*") (20 bytes): 6a3dc0ae9834bef9e35ebac3ac23f02f78c5f93b
> AUTH_r f6 a0 7c e5 dd 18 4b be c9 dc 06 de c7 c7 41 2d
> da 22 88 bc
> Notify: TS_UNACCEPTABLE (ESP spi=c9b5ce4d)
> SEND 124 bytes to 10.168.80.8[500] (7379.182)
> IKE_SA Created [v2 R](id=0xbd946a9e)
> CHILD_SA failed [v2 R], status = -8855
>
>
>
> [root at KAP8 etc]# cat ipsec.conf
> # ipsec.conf - strongSwan IPsec configuration file
>
> # basic configuration
>
> config setup
> # plutodebug=all
> # crlcheckinterval=600
> # strictcrlpolicy=yes
> # cachecrls=yes
> # nat_traversal=yes
> # charonstart=no
> plutostart=no
>
> # Add connections here.
>
> conn %default
> ikelifetime=60m
> keylife=20m
> rekeymargin=3m
> keyingtries=1
> mobike=no
> authby=secret
> keyexchange=ikev2
> #ike=aes256-sha256-ecp256,aes128-sha256-ecp256!
> #esp=aes256gcm16,aes128gcm16!
> esp=aes256gcm16-modp1024-modp2048,aes128gcm16-modp1024-modp2048!
>
> conn testipsec
> type=transport
> left=10.168.80.8
> #leftprotoport=icmp
> #leftid=kap
> right=10.168.65.1
> #rightprotoport=icmp
> #rightid=cep
> auto=add
======================================================================
Andreas Steffen andreas.steffen at strongswan.org
strongSwan - the Linux VPN Solution! www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20101115/85f42cc0/attachment.html>
More information about the Users
mailing list