[Swan] Does libreswan supports DH negotiation in ESP?
Ivan Kuznetsov
kia at solvo.ru
Wed May 17 13:36:24 UTC 2017
Hello
I trying to setup a site-to-site tunnel using ESP, IKEv2 and
certificates. My side is Oracle Linux 6 (a RHEL6 clone from Oracle),
libreswan 3.20, NETKEY stack as initiator. Other side is strongswan,
don't know exact version (not under my control), as responder.
My configuration:
conn TO_CLIENT
connaddrfamily=ipv4
type=tunnel
auto=ondemand
authby=rsasig
left=%defaultroute
leftsubnet=172.16.96.0/27
leftcert="VPN Certificate for supportsolvo"
leftid=%fromcert
leftrsasigkey=AbCdEfGhi
leftsendcert=always
right=client.router.fqdn
rightsubnets={172.16.71.0/26 172.16.17.0/24 172.16.40.0/26}
rightid=@client.router.fqdn
rightca=%same
ikev2=propose
ikelifetime=8h
initial-contact=yes
pfs=yes
ike=aes256-sha2;modp2048
phase2=esp
salifetime=80m
phase2alg=aes256-sha2;modp2048
rekey=yes
rekeymargin=10m
keyingtries=3
fragmentation=yes
nat_keepalive=yes
dpddelay=30
dpdtimeout=120
dpdaction=restart
Other side configration:
conn IKEv2-SOLVO
left=client.router.fqdn
leftcert=vpn3-host-cert.der
leftid=client.router.fqdn
leftsubnet=172.16.71.0/26
right=our.public.ip.network/24
rightcert=vpn3-supportsolvo-cert.der
rightid=vpn3-supportsolvo
rightsubnet=172.16.96.0/27
ike=aes256-sha256-modp2048!
esp=aes256-sha256-modp2048!
auto=add
Please note that modp2048 is configured for phase 2 on both sides
Tunnel is up on request (ipsec whack --initiate --name TO_CLIENT) and
works fine until a rekey request by other side in ~50min. I see in my
log that at initial time libreswan does not propose DH group at 2nd
phase, only 3 transorms:
May 16 12:55:39: | ******emit IKEv2 Proposal Substructure Payload:
May 16 12:55:39: | last proposal: v2_PROPOSAL_LAST (0x0)
May 16 12:55:39: | prop #: 1 (0x1)
May 16 12:55:39: | proto ID: IKEv2_SEC_PROTO_ESP (0x3)
May 16 12:55:39: | spi size: 4 (0x4)
May 16 12:55:39: | # transforms: 3 (0x3)
May 16 12:55:39: | emitting 4 raw bytes of our spi into IKEv2 Proposal
Substructure Payload
May 16 12:55:39: | our spi 79 2f b8 d4
May 16 12:55:39: | *******emit IKEv2 Transform Substructure Payload:
May 16 12:55:39: | last transform: v2_TRANSFORM_NON_LAST (0x3)
May 16 12:55:39: | IKEv2 transform type: TRANS_TYPE_ENCR (0x1)
May 16 12:55:39: | IKEv2 transform ID: AES_CBC (0xc)
May 16 12:55:39: | ********emit IKEv2 Attribute Substructure Payload:
May 16 12:55:39: | af+type: IKEv2_KEY_LENGTH (0x800e)
May 16 12:55:39: | length/value: 256 (0x100)
May 16 12:55:39: | emitting length of IKEv2 Transform Substructure
Payload: 12
May 16 12:55:39: | *******emit IKEv2 Transform Substructure Payload:
May 16 12:55:39: | last transform: v2_TRANSFORM_NON_LAST (0x3)
May 16 12:55:39: | IKEv2 transform type: TRANS_TYPE_INTEG (0x3)
May 16 12:55:39: | IKEv2 transform ID: AUTH_HMAC_SHA2_256_128 (0xc)
May 16 12:55:39: | emitting length of IKEv2 Transform Substructure
Payload: 8
May 16 12:55:39: | *******emit IKEv2 Transform Substructure Payload:
May 16 12:55:39: | last transform: v2_TRANSFORM_LAST (0x0)
May 16 12:55:39: | IKEv2 transform type: TRANS_TYPE_ESN (0x5)
May 16 12:55:39: | IKEv2 transform ID: ESN_DISABLED (0x0)
but some lines later shows:
May 16 12:55:39: "TO_CLIENT/0x1" #94: STATE_PARENT_I2: sent v2I2,
expected v2R2 {auth=IKEv2 cipher=aes_256 integ=sha256_128 prf=sha2_256
group=MODP2048}
Other side replay parsing:
May 16 12:55:39: | Comparing remote proposal 1 containing 3 transforms
against local proposal [1..1] of 1 local proposals
May 16 12:55:39: | ****parse IKEv2 Transform Substructure Payload:
May 16 12:55:39: | last transform: v2_TRANSFORM_NON_LAST (0x3)
May 16 12:55:39: | length: 12 (0xc)
May 16 12:55:39: | IKEv2 transform type: TRANS_TYPE_ENCR (0x1)
May 16 12:55:39: | IKEv2 transform ID: AES_CBC (0xc)
May 16 12:55:39: | *****parse IKEv2 Attribute Substructure Payload:
May 16 12:55:39: | af+type: IKEv2_KEY_LENGTH (0x800e)
May 16 12:55:39: | length/value: 256 (0x100)
May 16 12:55:39: | ****parse IKEv2 Transform Substructure Payload:
May 16 12:55:39: | last transform: v2_TRANSFORM_NON_LAST (0x3)
May 16 12:55:39: | length: 8 (0x8)
May 16 12:55:39: | IKEv2 transform type: TRANS_TYPE_INTEG (0x3)
May 16 12:55:39: | IKEv2 transform ID: AUTH_HMAC_SHA2_256_128 (0xc)
May 16 12:55:39: | ****parse IKEv2 Transform Substructure Payload:
May 16 12:55:39: | last transform: v2_TRANSFORM_LAST (0x0)
May 16 12:55:39: | length: 8 (0x8)
May 16 12:55:39: | IKEv2 transform type: TRANS_TYPE_ESN (0x5)
May 16 12:55:39: | IKEv2 transform ID: ESN_DISABLED (0x0)
May 16 12:55:39: | remote proposal 1 matches local proposal 1
May 16 12:55:39: | proposal
1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED[first-match]
was accepted
May 16 12:55:39: | ESP/AH ikev2_proposal:
1:ESP:SPI=c017160f;ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED
So it occured that DH group is NOT negotiated despite that modp2048 is
configured for ESP on both sides.
From 'man strongswan_ipsec.conf':
esp = <cipher suites>
[...]
If dh-group is specified, CHILD_SA rekeying and initial negotiation
include a separate Diffe-Hellman
exchange (since 5.0.0 this also applies to IKEv1 Quick Mode). However,
for IKEv2, the keys of the CHILD_SA
created implicitly with the IKE_SA will always be derived from the
IKE_SA's key material. So any DH group
specified here will only apply when the CHILD_SA is later rekeyed or is
created with a separate CREATE_CHILD_SA
exchange. Therefore, a proposal mismatch might not immediately be
noticed when the SA is established,
but may later cause rekeying to fail.
But no additional DH exchange occured. Later at rekeying time other side
remembers that DH group was configured and tries to negotiate a transorm
set with 4 transforms including DH group but fails:
May 16 13:41:49: | Comparing remote proposal 1 containing 4 transforms
against local proposal [1..1] of 1 local proposals
May 16 13:41:49: | ****parse IKEv2 Transform Substructure Payload:
May 16 13:41:49: | last transform: v2_TRANSFORM_NON_LAST (0x3)
May 16 13:41:49: | length: 12 (0xc)
May 16 13:41:49: | IKEv2 transform type: TRANS_TYPE_ENCR (0x1)
May 16 13:41:49: | IKEv2 transform ID: AES_CBC (0xc)
May 16 13:41:49: | *****parse IKEv2 Attribute Substructure Payload:
May 16 13:41:49: | af+type: IKEv2_KEY_LENGTH (0x800e)
May 16 13:41:49: | length/value: 256 (0x100)
May 16 13:41:49: | ****parse IKEv2 Transform Substructure Payload:
May 16 13:41:49: | last transform: v2_TRANSFORM_NON_LAST (0x3)
May 16 13:41:49: | length: 8 (0x8)
May 16 13:41:49: | IKEv2 transform type: TRANS_TYPE_INTEG (0x3)
May 16 13:41:49: | IKEv2 transform ID: AUTH_HMAC_SHA2_256_128 (0xc)
May 16 13:41:49: | ****parse IKEv2 Transform Substructure Payload:
May 16 13:41:49: | last transform: v2_TRANSFORM_NON_LAST (0x3)
May 16 13:41:49: | length: 8 (0x8)
May 16 13:41:49: | IKEv2 transform type: TRANS_TYPE_DH (0x4)
May 16 13:41:49: | IKEv2 transform ID: OAKLEY_GROUP_MODP2048 (0xe)
May 16 13:41:49: | ****parse IKEv2 Transform Substructure Payload:
May 16 13:41:49: | last transform: v2_TRANSFORM_LAST (0x0)
May 16 13:41:49: | length: 8 (0x8)
May 16 13:41:49: | IKEv2 transform type: TRANS_TYPE_ESN (0x5)
May 16 13:41:49: | IKEv2 transform ID: ESN_DISABLED (0x0)
May 16 13:41:49: | remote proposal 1 does not match; unmatched remote
transforms: DH
May 16 13:41:49: "TO_CLIENT/0x1" #95: no proposal chosen
from:1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048;ESN=DISABLED
Does DH negotiation is supported for ESP yet?
Ivan
More information about the Swan
mailing list