FortiClient Mac incapable of AES256?

[ispcolohost]

There seems to be no way to enter any advanced configuration in FortiClient for Mac?  I did export the config and in the <proposals> section, left it as just:

<proposal>aes256|sha256</proposal>

then imported back.  That changed nothing; when the FortiGate side was set with a phase 1 of only aes256/sha256, FortiClient Mac can't connect.  If I add back in encryption support for AES192 or 3DES, it will connect, which also seems odd considering I stripped all the other proposals out in the config I imported, so in theory, the client should be rejecting those.

Is there any way to make this work, as well as display the in-use encryption/authentication algorithms?  I can't find a way to display that on the client or gateway side. 

Yikes; on Android it appears to be even worse.  It doesn't even support SHA2 for auth and AES128 is the limit for encryption.  Why is it so out of date?

[emnoc]

What proposals do you have enabled on the fortigate?

e.g

"aes256-md5 3des-sha1 aes192-sha1"

[ispcolohost]

I was attempting to enable only aes256/sha256.  When the fortigate is set in that configuration, FortiClient for Mac cannot connect.  If I add in aes192 as an available encryption option, then it can.

Unfortunately, it gets even worse since I have to support android clients as well.  FortiClient for android can't even do sha2 on the auth side, or aes192 on the encryption side, so now I have to enable aes128/sha1 as well.

[emnoc]

Qs

Have you tried the macosx native client against your vpn profile to see what's being present & test the forticient 1st with that proposal?

I would debug the cipher proposal list ( diag debug app ike -1 ) and see what your client is sending and once again add that to the vpn profile cfg. Dump you cfg to a xml backup and validate the DHGRP and PROPOSAL in the cfg.

Diag sniffer paket the traffic from the client to ensure the client is sending ike to the fortigate and review the phase2 settings also.

I found that changing xml cfg and re-importing doesn't always take place and active. So you might need to shutdown the  forticlient and re-launch it.

btw:

<proposal>AES256|SHA256<proposal>

[ispcolohost]

I did some further testing.  The FortiClient for Mac actually will do AES256 encryption, turns out the AES128 limit is only during phase 1.  Similarly, you can also do SHA256 auth in phase 2, but it can only do SHA1 auth for phase 1.  So, if only supporting FortiClient Mac, FortiClient Windows and iOS users, your minimal config must permit:

Phase 1: AES256-SHA256, AES128-SHA1 (for iOS & Mac), DH 2 (for iOS & Mac)/5/14

Phase 2: AES256-SHA256, AES256-SHA1 (for iOS), DH 2 (for iOS)/5/14

Of course, all of this is negated by the FortiClient for Android, which is still unable to do better than AES128-SHA1 for phase 1 and 2, so if you have Android users, you must add AES128-SHA1 into phase 2.

I guess the end result of this quest has been learning that we're going to be stuck with dated protocols until Fortinet releases a native iOS client (or Apple/Cisco updates the built-in one), until they release a MacOS client comparable to the Windows client, and until they update the very behind Android client.

[emnoc]

Good to know. Be advise most dynamic vpn clients don't support sha256/384/512. Unless your really paranoid AES128 and sha1 is more than enough for the 9 out of 10 end-users.

The native Android & WindowOS ( L2TPipsec) are both  stuck with basic sha1 support and 3des or AES with dhgrp 1,2,5  for  key strength.