Houman,
No need to configure a prf, it is already assumed when you
configured a DH group; so you can drop prfsha256. And as Christian
suggested, if all your clients support strong encryption drop all weak
algorithms/proposals from the server end i.e 3des, sha1, modp1024. I
can't believe that Microsoft still in 2018 offer these as the default
options and expects users to go tinker with obscured registery keys to
enable stronger options.
For ESP, I'd connect the Windows client and see what the offered
proposals in the logs at the server side, just as you did with ike. You
can then limit the proposals at the server end to the good ones. If I
remember well, AES256 was an option, but esp didn't allow a DH group so
you might need to drop that, but I could be wrong.
Cheers,
Jafar
On 5/8/2018 1:55 PM, Houman wrote:
Thank you both Christian and Jafar for the clear proposals.
So yes, if I wanted to support Windows 10, iOS/OSX and Linux with the
stronger set of encryption. Do I set *aes256-sha256-prfsha256-modp2048
*into *ike* only? Or both in *ike* and *esp*?
This part wasn't quite clear to me.
Yeah, I have already set [NegotiateDH2048_AES256] in Windows 10.
Many Thanks,
Houman
On 8 May 2018 at 08:40, Christian Salway <christian.sal...@naimuri.com
<mailto:christian.sal...@naimuri.com>> wrote:
The problem with Windows (10 at least) is that it offers the
weakest ciphers first, so you should remove sha1 and 3des.
The minimum proposals you should have and which are compatible
with Windows 10, OSX, IOS and Linux are the following.
*proposals = aes256-sha256-prfsha256-modp2048-modp1024*
Although I would recommend adding the Windows 10 registry key
[NegotiateDH2048_AES256] to use strong ciphers and then you can
remove MODP1024
<http://www.naimuri.com>
On 7 May 2018, at 15:50, Jafar Al-Gharaibeh <ja...@atcorp.com
<mailto:ja...@atcorp.com>> wrote:
Houman,
The Windows client proposals do not match your configured
proposals. Your Windows client expect DG group 15 (MODP2048),
where as you have:
aes256-3des-sha1-modp1024
change that to:
aes256-3des-sha1-modp2048
I'd also add sha256 at least before sha1 (deemed insecure). If
you still have other clients expecting modp1024, make it:
aes256-3des-sha256-sha1-modp2048-modp1024
That should get you covered.
Regards,
Jafar
On 5/7/2018 8:17 AM, Houman wrote:
Hello,
Until a week ago a user with Windows 10 had no issue connecting
to the StrongSwan server. But now out of the blue, he can't
connect to the StrongSwan server anymore.
The log on the server is:
May 7 12:31:06 vpn-p1 charon: 08[IKE] received proposals
inacceptable
May 7 12:31:06 vpn-p1 charon: 08[ENC] generating IKE_SA_INIT
response 0 [ N(NO_PROP) ]
May 7 12:31:06 vpn-p1 charon: 08[NET] sending packet: from
xxx.x.xx.92[500] to 91.98.xxx.xxx[500] (36 bytes)
May 7 12:32:09 vpn-p1 systemd[1]: Started Session 35 of user root.
May 7 12:46:21 vpn-p1 systemd[1]: Starting Cleanup of Temporary
Directories...
May 7 12:46:21 vpn-p1 systemd-tmpfiles[7016]:
[/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path
"/var/log", ignoring.
May 7 12:46:21 vpn-p1 systemd[1]: Started Cleanup of Temporary
Directories.
May 7 13:00:13 vpn-p1 systemd[1]: Starting Certbot...
May 7 13:00:13 vpn-p1 systemd[1]: Started Certbot.
May 7 13:08:20 vpn-p1 systemd[1]: Started Session 36 of user root.
May 7 13:11:27 vpn-p1 charon: 12[NET] received packet: from
91.98.xxx.xxx[500] to xxx.x.xx.92[500] (624 bytes)
May 7 13:11:27 vpn-p1 charon: 12[ENC] parsed IKE_SA_INIT
request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V V V V ]
May 7 13:11:27 vpn-p1 charon: 12[IKE] received MS NT5
ISAKMPOAKLEY v9 vendor ID
May 7 13:11:27 vpn-p1 charon: 12[IKE] received MS-Negotiation
Discovery Capable vendor ID
May 7 13:11:27 vpn-p1 charon: 12[IKE] received
Vid-Initial-Contact vendor ID
May 7 13:11:27 vpn-p1 charon: 12[ENC] received unknown vendor
ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02
May 7 13:11:27 vpn-p1 charon: 12[IKE] 91.98.xxx.xxx is
initiating an IKE_SA
May 7 13:11:27 vpn-p1 charon: 12[CFG] received proposals:
IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048,
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048,
IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_2048
May 7 13:11:27 vpn-p1 charon: 12[CFG] configured proposals:
IKE:AES_GCM_16_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_521,
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_384,
IKE:AES_CBC_256/3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
May 7 13:11:27 vpn-p1 charon: 12[IKE] remote host is behind NAT
May 7 13:11:27 vpn-p1 charon: 12[IKE] received proposals
inacceptable
May 7 13:11:27 vpn-p1 charon: 12[ENC] generating IKE_SA_INIT
response 0 [ N(NO_PROP) ]
May 7 13:11:27 vpn-p1 charon: 12[NET] sending packet: from
xxx.x.xx.92[500] to 91.98.xxx.xxx[500] (36 bytes)
May 7 13:11:28 vpn-p1 charon: 16[NET] received packet: from
91.98.xxx.xxx[500] to xxx.x.xx.92[500] (624 bytes)
May 7 13:11:28 vpn-p1 charon: 16[ENC] parsed IKE_SA_INIT
request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V V V V ]
May 7 13:11:28 vpn-p1 charon: 16[IKE] received MS NT5
ISAKMPOAKLEY v9 vendor ID
May 7 13:11:28 vpn-p1 charon: 16[IKE] received MS-Negotiation
Discovery Capable vendor ID
May 7 13:11:28 vpn-p1 charon: 16[IKE] received
Vid-Initial-Contact vendor ID
May 7 13:11:28 vpn-p1 charon: 16[ENC] received unknown vendor
ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02
May 7 13:11:28 vpn-p1 charon: 16[IKE] 91.98.xxx.xxx is
initiating an IKE_SA
May 7 13:11:28 vpn-p1 charon: 16[CFG] received proposals:
IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048,
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048,
IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_2048
May 7 13:11:28 vpn-p1 charon: 16[CFG] configured proposals:
IKE:AES_GCM_16_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_521,
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_384,
IKE:AES_CBC_256/3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
May 7 13:11:28 vpn-p1 charon: 16[IKE] remote host is behind NAT
May 7 13:11:28 vpn-p1 charon: 16[IKE] received proposals
inacceptable
May 7 13:11:28 vpn-p1 charon: 16[ENC] generating IKE_SA_INIT
response 0 [ N(NO_PROP) ]
May 7 13:11:28 vpn-p1 charon: 16[NET] sending packet: from
xxx.x.xx.92[500] to 91.98.xxx.xxx[500] (36 bytes)
The Server's ipsec.conf is:
config setup
strictcrlpolicy=yes
uniqueids=never
conn roadwarrior
auto=add
compress=no
type=tunnel
keyexchange=ikev2
fragmentation=yes
forceencaps=yes
ike=aes256gcm16-sha256-ecp521,aes256-sha256-ecp384,aes256-3des-sha1-modp1024!
esp=aes256gcm16-sha256,aes256-3des-sha256-sha1!
dpdaction=clear
dpddelay=180s
rekey=no
left=%any
leftid=@${VPNHOST}
leftcert=cert.pem
leftsendcert=always
leftsubnet=0.0.0.0/0 <http://0.0.0.0/0>
right=%any
rightid=%any
rightauth=eap-radius
eap_identity=%any
rightdns=208.67.222.222,208.67.220.220
rightsourceip=${VPNIPPOOL}
rightsendcert=never
Have the supported ike/esp proposals somehow been changed
recently after a recent Windows 10 update?
I have made these changes on the Windows 10, after googling for
a solution:
- The firewall on Windows 10 is currently disabled.
- I have set NegotiateDH2048_AES256 = 1 in Regedit
- AssumeUDPEncapsulationContextOnSendRule = 2 in Regedit
I can't think of anything else I could do on the Windows 10 client.
According to my notes, these are the proposed protocols for
Windows 10:
# these ike and esp settings are tested on Mac 10.12, iOS 10 and
Windows 10
# iOS/Mac with appropriate configuration profiles use
AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_521
# Windows 10 uses
AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_384
Is there a website that translates
AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_384 into the
right naming for ipsec.conf so that I enter them under ike and
esp respectively? I can't quite make out if I have these
settings there or not.
If you have any other advice, please help me.
Many Thanks,
