Thursday, May 31, 2018

FortiClient IPSEC beaware of keyid

Over the last 3 weeks,  I have  had about 4 requests in trying to  help others with  using the fortiClient as a  ipsec-client  &  for accessing nonFortigate appliance. I was successful in  3 out of 4 devices.


One thing that was over looked by the other administrators, the  IPSEC-GW needs the proper keyid value and not FQDN or username during IKEv1 setup. You can have all of the correct  auth/encryption proposals  defined,  and the proper localid ( aka  group_name ) , but if the responder is expecting   a FQDN, the  fortiClient  will not work in most cases.


This two screen shows will show the fortiClient  and the idtype value of keyid vrs FQDN capture from a tcpdump



So if you have a ipsec-gateway set the  group idtype to  be keyid  if you want to  use the fortiClient.


On a Fortigate appliance they typically don't care and use a type of "any" unless you hard code it.

 example.


NOTE: these values are sent in the clear &  when  IKEv1 is  being used along with aggressive-mode,  this is why  ikescan attacks and weak PreShareKeys are  quick to be brute-force. So if you use  IKEv1 , try to    set very long pre-share-keys and if your using  XAUTH for dynamic-remote users, very long  password or even  better a hybrid of  PSK+XAUTH+MFA

http://www.nta-monitor.com/wiki/index.php/Ike-scan_User_Guide

http://socpuppet.blogspot.com/2015/10/the-forticlient-and-cisco-vpn-ipsec.html







NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
     ^      ^
=(  @  @ )=
         o
        /  \
 

No comments:

Post a Comment