[strongSwan] no acceptable proposal found even though it has matching proposal
Yogesh Purohit
yogeshpurohit2 at gmail.com
Wed Oct 10 11:54:29 CEST 2018
Hi Team,
I had configured Strongswan on both side as initiator and as responder with
below mentioned configuration:
Initiator config:
conn %default
ikelifetime = 28800s
type = tunnel
lifetime = 3600s
dpddelay = 30
dpdaction = restart
reauth = no
mobike = no #disable mobike - no use case
conn 10.109.229.252_2.1.1.0/24-10.109.229.250_1.1.2.0/24
left=10.109.229.252
leftid=10.109.229.252
rightid=10.109.229.250
leftsubnet=2.1.1.0/24
right=10.109.229.250
rightsubnet=1.1.2.0/24
authby=secret
keyexchange = ikev2
auto = start
fragmentation = yes
esp=aes256-sha256-modp2048!
ike=aes256-sha256-modp2048
conn 10.109.229.252_2.1.2.0/24-10.109.229.250_1.1.2.0/24
left=10.109.229.252
leftid=10.109.229.252
rightid=10.109.229.250
leftsubnet=2.1.2.0/24
right=10.109.229.250
rightsubnet=1.1.2.0/24
authby=secret
keyexchange = ikev2
auto = start
fragmentation = yes
esp=aes256-sha256-modp2048!
ike=aes256-sha256-modp2048
Responder Configuration:
conn %default
ikelifetime = 28800s
type = tunnel
lifetime = 3600s
dpddelay = 30
dpdaction = restart
reauth = no
mobike = no #disable mobike - no use case
conn 10.109.229.250_1.1.2.0/24-10.109.229.252_2.1.1.0/24
left=10.109.229.250
leftid=10.109.229.250
rightid=10.109.229.252
leftsubnet=1.1.2.0/24
right=10.109.229.252
rightsubnet=2.1.1.0/24
authby=secret
keyexchange = ikev2
auto = add
fragmentation = yes
esp=aes256-sha1-modp2048
ike=aes256-sha1-modp2048!
conn 10.109.229.250_1.1.2.0/24-10.109.229.252_2.1.2.0/24
left=10.109.229.250
leftid=10.109.229.250
rightid=10.109.229.252
leftsubnet=1.1.2.0/24
right=10.109.229.252
rightsubnet=2.1.2.0/24
authby=secret
keyexchange = ikev2
auto = add
fragmentation = yes
esp=aes256-sha1-modp2048
ike=aes256-sha1-modp2048!
So when I started initiation for the tunnels.
Only one IPsec SA came up whereas other IPsec SA was rejected with reason
as 'No Proposal Found' even though proposal configured was present there
I have attached small snippet of the log below for the case.
For the IPsec SA created with IKE_AUTH:
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> looking for a
child config for 1.1.2.0/24 === 2.1.1.0/24
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> proposing traffic
selectors for us:
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> 1.1.2.0/24
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> proposing traffic
selectors for other:
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> 2.1.2.0/24
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> proposing traffic
selectors for us:
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> 1.1.2.0/24
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> proposing traffic
selectors for other:
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> 2.1.1.0/24
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> candidate
"10.109.229.250_1.1.2.0/24-10.109.229.252_2.1.1.0/24" with prio 5+5
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> found matching
child config "10.109.229.250_1.1.2.0/24-10.109.229.252_2.1.1.0/24" with
prio 10
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> selecting proposal:
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> no acceptable
INTEGRITY_ALGORITHM found
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> selecting proposal:
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> proposal matches
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> received
proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> configured
proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ,
ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/BLOWFISH_CBC_256/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/NO_EXT_SEQ
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> selected proposal:
ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> got SPI c671babe
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> selecting traffic
selectors for us:
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> config: 1.1.2.0/24,
received: 1.1.2.0/24 => match: 1.1.2.0/24
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> selecting traffic
selectors for other:
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> config: 2.1.1.0/24,
received: 2.1.1.0/24 => match: 2.1.1.0/24
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> using AES_CBC
for encryption
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> using
HMAC_SHA2_256_128 for integrity
And for the separate CHILD_SA:
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> looking for a
child config for 1.1.2.0/24 === 2.1.2.0/24
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> proposing traffic
selectors for us:
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> 1.1.2.0/24
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> proposing traffic
selectors for other:
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> 2.1.2.0/24
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> candidate
"10.109.229.250_1.1.2.0/24-10.109.229.252_2.1.2.0/24" with prio 5+5
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> proposing traffic
selectors for us:
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> 1.1.2.0/24
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> proposing traffic
selectors for other:
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> 2.1.1.0/24
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> found matching
child config "10.109.229.250_1.1.2.0/24-10.109.229.252_2.1.2.0/24" with
prio 10
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> selecting proposal:
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> no acceptable
INTEGRITY_ALGORITHM found
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> selecting proposal:
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> no acceptable
DIFFIE_HELLMAN_GROUP found
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> received
proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> configured
proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ,
ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/BLOWFISH_CBC_256/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/NO_EXT_SEQ
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> no acceptable
proposal found
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> Setting alert and
state in for child_cfg
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32>
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> added payload of
type NOTIFY to message
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> failed to
establish CHILD_SA, keeping IKE_SA
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> Received an alert
which is not handled.
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32>
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> order payloads in
message
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> added payload of
type NOTIFY to message
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> generating
CREATE_CHILD_SA response 2 [ N(NO_PROP) ]
<10.109.229.250_1.1.1.0/24-10.109.229.252_2.1.1.0/24|32> insert payload
NOTIFY into encrypted payload
So my query is, in CHILD_SA, even DH group received and configured are
matching still it says no acceptable DH group and rejects the connection
with 'No Prop'
Why is it saying no acceptable DH group when it is same ?
Thanks for the reply.
--
Best Regards,
Yogesh Purohit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20181010/8d3c1c59/attachment.html>
More information about the Users
mailing list